Messages in this thread | | | Date | Fri, 8 Mar 2019 16:30:23 +0100 | From | Frederic Weisbecker <> | Subject | Re: [PATCH 00/37] softirq: Per vector masking v3 |
| |
On Fri, Mar 01, 2019 at 08:51:38AM -0800, Linus Torvalds wrote: > On Thu, Feb 28, 2019 at 7:45 PM Frederic Weisbecker <frederic@kernel.org> wrote: > > > > Numbers are indeed missing. In fact this patchset mostly just brings an > > infrastructure. We have yet to pinpoint the most latency-inducing > > softirq disabled sites and make them disable only the vectors that > > are involved in a given lock. > > Note that I think we pretty much know that already: the people who > have had issues have never actually really had issues with the actual > "disable softirq" paths, they've all been about actually *running* the > softirq's (and that in turn being a latency issue for running _other_ > softirqs, and in particular for delaying them into softirqd). > > Now, it may well be that yes, we'll have "block softirqs" code that > has issues too, but it's absolutely been swamped by the latencies for > actually running them so far. > > Note that this is all really fairly independent of the whole masking > logic. Yes, the masking logic comes into play too (allowing you to run > a subset of softirq's at a time), but on the whole the complaints I've > seen have not been "the networking softirq takes so long that it > delays USB tasklet handling", but they have been along the lines of > "the networking softirq gets invoked so often that it then floods the > system and triggers softirqd, and _that_ then makes tasklet handling > latency go up insanely". > > See the difference? Not the latency of softirq's disabled, but the > latency of one group of softirqs causing problems for another when > they all get batched together (and soft-scheduled to another context > together).
I see, so that's an entirely different problem that vector soft-interruptibility can't fix, at least not alone.
The only solution I can imagine is to have a seperate pending mask for normal softirq processing and ksoftirqd, so that only vectors that have been enqueued for threaded processing are delayed.
I can work on that first, but I really need to be able to reproduce an example of the issue. The USB capture thing seems to be one the best. Let's browse some history to see if I can find some details on the relevant scenario.
| |