Messages in this thread | | | Date | Tue, 10 May 2022 18:19:19 +0200 | From | Peter Zijlstra <> | Subject | Re: Folllowing up on LSF/MM RCU/idle discussion |
| |
On Tue, May 10, 2022 at 10:43:51AM +0100, Mark Rutland wrote: > On Tue, May 10, 2022 at 08:54:57AM +0200, Peter Zijlstra wrote: > > On Mon, May 09, 2022 at 08:56:33AM -0700, Paul E. McKenney wrote: > > > Hello, Jiri! > > > > > > It was good chatting with you last week, and I hope that travels went > > > well! > > > > > > Just wanted to follow up on the non-noinstr code between the call > > > to rcu_idle_enter() and rcu_idle_exit(). Although the most correct > > > approach is to never have non-noinstr code in arch_cpu_idle(), for all I > > > know there might well be architectures for which this is not feasible. > > > If so, one workaround would be to supply a flag set by each arch (or > > > subarch) that says that rcu_idle_enter() and rcu_idle_exit() are invoked > > > within arch_cpu_idle(). > > > > > > CCing Peter, who just might have an opinion on this. ;-) > > > > Definitely have an opinion; just lack the tools to enforce these rules. > > I cleaned up the worst of it for x86 but it's a shit-show for most > > others. ARM in particular has some 'issues'. > > Probably worth pointing out that arch_cpu_idle() is the simple case (and I > fixed that for arm64 to be correct for RCU and noinstr). I think the same > applies for most architectures. > > The real beast is the cpuidle framework, which is what I think you're referring > to below, and IIRC that does the rcu_idle_enter() ... rcu_idle_exit() itself? > Maybe that was just for suspend.
The whole group idle nonsense on arm32 was the worse I think.
| |