Messages in this thread | | | Date | Mon, 6 Mar 2023 12:22:26 +0100 | From | Frederic Weisbecker <> | Subject | Re: [PATCH 2/3] softirq: avoid spurious stalls due to need_resched() |
| |
On Sun, Mar 05, 2023 at 08:30:33PM -0800, Paul E. McKenney wrote: > On Mon, Mar 06, 2023 at 12:00:24AM +0100, Frederic Weisbecker wrote: > > On Sun, Mar 05, 2023 at 02:42:11PM -0800, Paul E. McKenney wrote: > > > On Sun, Mar 05, 2023 at 09:43:23PM +0100, Thomas Gleixner wrote: > > > Indeed, as you well know, CONFIG_RCU_NOCB_CPU=y in combination with the > > > rcutree.use_softirq kernel boot parameter in combination with either the > > > nohz_full or rcu_nocbs kernel boot parameter and then the callbacks are > > > invoked within separate kthreads so that the scheduler has full control. > > > In addition, this dispenses with all of the heuristics that are otherwise > > > necessary to avoid invoking too many callbacks in one shot. > > > > > > Back in the day, I tried making this the default (with an eye towards > > > making it the sole callback-execution scheme), but this resulted in > > > some ugly performance regressions. This was in part due to the extra > > > synchronization required to queue a callback and in part due to the > > > higher average cost of a wakeup compared to a raise_softirq(). > > > > > > So I changed to the current non-default arrangement. > > > > > > And of course, you can do it halfway by booting kernel built with > > > CONFIG_RCU_NOCB_CPU=n with the rcutree.use_softirq kernel boot parameter. > > > But then the callback-invocation-limit heuristics are still used, but > > > this time to prevent callback invocation from preventing the CPU from > > > reporting quiescent states. But if this was the only case, simpler > > > heuristics would suffice. > > > > > > In short, it is not hard to make RCU avoid using softirq, but doing so > > > is not without side effects. ;-) > > > > Right but note that, threaded or not, callbacks invocation happen > > within a local_bh_disable() section, preventing other softirqs from running. > > > > So this is still subject to the softirq per-CPU BKL. > > True enough! But it momentarily enables BH after invoking each callback, > so the other softirq vectors should be able to get a word in.
Indeed it's still less worse than having it in softirqs.
| |