Hi, I've found the answer for my first question:
On Wednesday, November 27, 2013 2:37 PM Zhou, Han wrote: > However, there are still things unclear to me: > 1. I see in the code that a miss_handler should be woken up only when it has > 50 > upcalls pending by dispatcher, but why my test shows they always wakeup from > ovs_mutex_cond_wait() with only 1 or 2 upcalls for them (rarely wakeup when > there is no upcalls)? Is there any other wakeup mechanism I missed? The miss_handlers are woken up frequently by the dispatcher outside of the for (;;) loop, because the for loop breaks when dpif_recv() returns EAGAIN, which happens far more frequently than there are 50 pending upcalls for a handler. I am trying to figure out a quick but safe solution for this high CPU issue: increase batch mode probability while avoid hanging forever. For the second question: > 2. why ovs-vswitchd occupies so much CPU in short-lived flow test before my > change? And why it drops so dramatically? What's the contention between > ovs-vswitchd and miss_handler? I didn't find the exact answer yet, but I did observe that there are many mutex contentions by checking strace results. Sorry that I am still new to OVS code, so need more time to dig out :) Alex, I just saw your another patch for fairness of dispatcher algorithm, do you have any thoughts on below proposal for more scalable multi-threading, removing dispatcher completely? Thanks! > > A better solution for this bottleneck of dispatcher, in my opinion, could be > that > each handler thread receives upcalls assigned to them from kernel directly > thus > no conditional wait and signal involved, which avoid unnecessary context > switch > and futex scalling problem in multicore env. The selection of handler can be > done by kernel with same kind of hash, but put into different queues > per-handler, and this way packet order is preserved. Can this be a valid > proposal? > Best regards, Han _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
