This thread is starting to get a bit confusing, at least for people with a single-pipeline brain like me!
I am not entirely sure if I understand correctly Isaku's proposal concerning deferring the application of flow changes. I think it's worth discussing in a separate thread, and a supporting patch will help as well; I think that in order to avoid unexpected behaviours, vlan tagging on the port and flow setup should always be performed at the same time; if we get a much better performance using a mechanism similar to iptables' defer_apply, then we should it. Regarding rootwrap. This 6x slowdown, while proving that rootwrap imposes a non-negligible overhead, it should not be used as a sort of proof that rootwrap makes things 6 times worse! What I've been seeing on the gate and in my tests are ALRM_CLOCK errors raised by ovs commands, so rootwrap has little to do with it. Still, I think we can say that rootwrap adds about 50ms to each command, becoming particularly penalising especially for 'fast' commands. I think the best things to do, as Joe advices, a test with rootwrap disabled on the gate - and I will take care of that. On the other hand, I would invite community members picking up some of the bugs we've registered for 'less frequent' failures observed during parallel testing; especially if you're coming to Montreal next week. Salvatore On 6 January 2014 20:31, Jay Pipes <[email protected]> wrote: > On Mon, 2014-01-06 at 11:17 -0800, Joe Gordon wrote: > > > > > > > > On Mon, Jan 6, 2014 at 10:35 AM, Jay Pipes <[email protected]> wrote: > > On Mon, 2014-01-06 at 09:56 -0800, Joe Gordon wrote: > > > > > What about it? Also those numbers are pretty old at this > > point. I was > > > thinking disable rootwrap and run full parallel tempest > > against it. > > > > > > I think that is a little overkill for what we're trying to do > > here. We > > are specifically talking about combining many utils.execute() > > calls into > > a single one. I think it's pretty obvious that the latter will > > be better > > performing than the first, unless you think that rootwrap has > > no > > performance overhead at all? > > > > > > mocking out rootwrap with straight sudo, is a very quick way to > > approximate the performance benefit of combining many utlils.execute() > > calls together (at least rootwrap wise). Also it would tell us how > > much of the problem is rootwrap induced and how much is other. > > Yes, I understand that, which is what the article I linked earlier > showed? > > % time sudo ip link >/dev/null > sudo ip link > /dev/null 0.00s user 0.00s system 43% cpu 0.009 total > % sudo time quantum-rootwrap /etc/quantum/rootwrap.conf ip link > > /dev/null > quantum-rootwrap /etc/quantum/rootwrap.conf ip link > /dev/null 0.04s > user 0.02s system 87% cpu 0.059 total > > A very tiny, non-scientific simple indication that rootwrap is around 6 > times slower than a simple sudo call. > > Best, > -jay > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
