On Tue, Sep 02, 2014 at 09:15:18AM +0300, Eliezer Tamir wrote: > On 02/09/2014 06:29, Jason Wang wrote: > > On 09/01/2014 02:39 PM, Eliezer Tamir wrote: > >> On 29/08/2014 06:08, Jason Wang wrote: > >>>> Yes, but rx busy polling only works in process context and does not > >>>> disable bh, so it may be not an issue. > >> sk_busy_loop() uses rcu_read_lock_bh(), so it does run with bh disabled. > > > > True, so we need probably also exit the loop when there are pending bhs. > > I'm not so sure, in the typical busy poll scenario, the incoming > traffic is the most time-critical thing in the system. > It's so important that you are willing to trade lots of CPU power > for better latency. The user has decided that he wants to dedicate > this CPU mostly for that. This is not something that plays nice with > other apps, but this is what the user wants.
I think most applications wouldn't interpret this flag as "burn up CPU I don't care what is the result", what apps want is more of "maximise throughput and minimise latency even if throughput/CPU ratio goes down". Jason posted benchmarks that show throughput going up because other processes get more of a chance to run, so this seems consistent with that goal. > So, you definitely don't want to starve any bh, and you should > regularly re-enable bh's, but you also don't want to stop everything > at any time a bh is scheduled. > > You also want network processing on the queues that are busy polled > to come through busy polling and not through NAPI, which is run in bh > context. > > -Eliezer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
