On 10.05.2016 23:09, Eric Dumazet wrote: > On Tue, May 10, 2016 at 1:46 PM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: > >> I agree here, but I don't think this patch particularly is a lot of >> bloat and something very interesting people can play with and extend upon. >> > > Sure, very rarely patch authors think their stuff is bloat. > > I prefer to fix kernel softirq.c, or at least show me that you tried > hard enough. > > I am pretty sure that the following would work : > > When ksoftirqd is scheduled, remember this in a per cpu variable > (ksoftiqd_scheduled) > > When enabling BH , do not call do_softirq() if this variable is set. > > ksoftirqd would clear the variable at the right place (probably in > run_ksoftirqd()) > > Sure, this might add a lot of latency regressions, but lets fix them.
Probably, yes. We had a version which limited the number of restarts if softirqs were invoked from local_bh_enable (so that at least timers etc. would run) and would defer all other work to ksoftirqd. That also solved the initial live lock problem. I do have concerns about the fairness of this approach, but we now have to investigate this. ;) Not only did we want to present this solely as a bugfix but also as as performance enhancements in case of virtio (as you can see in the cover letter). Given that a long time ago there was a tendency to remove softirqs completely, we thought it might be very interesting, that a threaded napi in general seems to be absolutely viable nowadays and might offer new features. Bye, Hannes