[ovs-dev] thundering herd wakeup of handler threads

David Ahern dsahern at gmail.com
Wed Mar 11 19:26:01 UTC 2020


On 1/8/20 9:18 AM, Aaron Conole wrote:
> David Ahern <dsahern at gmail.com> writes:
> 
>> On 12/16/19 2:42 PM, Aaron Conole wrote:
>>> Can you try the following and see if your scalability issue is
>>> addressed?  I think it could be better integrated, but this is a
>>> different quick 'n dirty.
>>
>> your patch reduces the number of threads awakened, but it is still
>> really high - 43 out of 71 handler threads in one test.
> 
> Thanks for getting back to me (sorry for the late response, catching
> up).  I'll take a closer look.  I haven't thought about adding
> EPOLLEXCLUSIVE to the poll block change, so maybe that will address it
> completely, or maybe there's a different approach.
> 

This seems to have gone quiet for a few months now. In case my previous
comments weren't clear, the change in question
(69c51582ff786a68fc325c1c50624715482bc460) converted a control plane
scaling problem into a datapath scaling problem. It manifests as an
increase in squeezed counts and dropped packets (both at the enqueue
point and at hand off to the vhost threads) because of the increased
time spent on upcalls.

I have reverted that commit and several on top of it for our purposes,
but this really is something OVS devs should fix.


More information about the dev mailing list