[openstack-dev] [Neutron][qa] Parallel testing update

Mathieu Rohon mathieu.rohon at gmail.com
Tue Jan 7 13:08:05 UTC 2014


I think that isaku is talking about a more intensive usage of
defer_apply_on/off as it is done in the patch of gongysh [1].

Isaku, i don't see any reason why this could not be done in
precess_network_ports, if needed. Moreover the patch from edouard [2]
resolves multithreading issues while precessing defer_apply_off.


[1]https://review.openstack.org/#/c/61341/
[2]https://review.openstack.org/#/c/63917/

On Mon, Jan 6, 2014 at 9:24 PM, Salvatore Orlando <sorlando at nicira.com> wrote:
> 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 <jaypipes at gmail.com> wrote:
>>
>> On Mon, 2014-01-06 at 11:17 -0800, Joe Gordon wrote:
>> >
>> >
>> >
>> > On Mon, Jan 6, 2014 at 10:35 AM, Jay Pipes <jaypipes at gmail.com> 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
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



More information about the OpenStack-dev mailing list