Messages in this thread | | | Subject | Re: [RFC PATCH 2/4] softirq: Per vector deferment to workqueue | From | Dmitry Safonov <> | Date | Thu, 08 Feb 2018 20:30:20 +0000 |
| |
On Thu, 2018-02-08 at 15:22 -0500, David Miller wrote: > From: Dmitry Safonov <dima@arista.com> > Date: Thu, 08 Feb 2018 20:14:55 +0000 > > > On Thu, 2018-02-08 at 13:45 -0500, David Miller wrote: > >> From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> > >> Date: Thu, 8 Feb 2018 18:44:52 +0100 > >> > >> > May I instead suggest to stick to ksoftirqd? So you run in > softirq > >> > context (after return from IRQ) and if takes too long, you > offload > >> the > >> > vector to ksoftirqd instead. You may want to play with the > metric > >> on > >> > which you decide when you want switch to ksoftirqd / account how > >> long a > >> > vector runs. > >> > >> Having read over this stuff for the past few weeks this is how I > feel > >> as well. Just make ksofbitrq do what we want (only execute the > >> overloaded softirq vectors). > >> > >> The more I look at the workqueue stuff, the more complications and > >> weird behavioral artifacts we are getting for questionable gain. > > > > What about creating several ksoftirqd threads per-cpu? > > Like I did with boot parameter to specify how many threads and > which > > softirqs to serve. > > Why do we need more than one per cpu?
Ugh, yeah, I remember why I did it - I tried to reuse scheduler for each ksoftirqd thread to decide if it need to run now or later. That would give an admin a way to prioritise softirqs with nice. Not sure if it's a nice idea at all..
> > There is a set of vectors which are "overloaded" and ksoftirqd > processes > them one by one. > > The only difference with what happens now is that one softirq being > overloaded doesn't defer the processing of all softirqs to ksoftirqd.
| |