Messages in this thread | | | Date | Thu, 27 Aug 2020 18:30:01 -0400 | From | Joel Fernandes <> | Subject | Re: [PATCH v2 03/11] sched,idle,rcu: Push rcu_idle deeper into the idle path |
| |
On Thu, Aug 27, 2020 at 09:47:48AM +0200, peterz@infradead.org wrote: > On Wed, Aug 26, 2020 at 09:24:19PM -0400, Joel Fernandes wrote: > > On Wed, Aug 26, 2020 at 09:18:26PM -0400, Joel Fernandes wrote: > > > On Fri, Aug 21, 2020 at 10:47:41AM +0200, Peter Zijlstra wrote: > > > > Lots of things take locks, due to a wee bug, rcu_lockdep didn't notice > > > > that the locking tracepoints were using RCU. > > > > > > > > Push rcu_idle_{enter,exit}() as deep as possible into the idle paths, > > > > this also resolves a lot of _rcuidle()/RCU_NONIDLE() usage. > > > > > > > > Specifically, sched_clock_idle_wakeup_event() will use ktime which > > > > will use seqlocks which will tickle lockdep, and > > > > stop_critical_timings() uses lock. > > > > > > I was wondering if those tracepoints should just use _rcuidle variant of the > > > trace call. But that's a terrible idea considering that would add unwanted > > > overhead I think. > > > > > > Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org> > > > > BTW, if tracepoint is converted to use RCU-trace flavor, then these kinds of > > issues go away, no? That RCU flavor is always watching. > > All trace_*_rcuidle() and RCU_NONIDLE() usage is a bug IMO. > > Ideally RCU-trace goes away too.
I was thinking that unless the rcu_idle_enter/exit calls coincide with points in the kernel where instrumentation is not allowed, there is always a chance somebody wants to use tracepoints after rcu_idle_enter or before exit. In this case, trace_*_rcuidle() is unavoidable unless you can move the rcu_idle_enter/exit calls deeper as you are doing.
Maybe objtool can help with that?
The other solution is RCU-trace if you can't push the rcu_idle_enter/exit calls any deeper and still want to get rid of trace_*_rcuidle thingies. Me and Mathieu were talking at LPC about tracepoint conversion to RCU-trace and we can work on it if that's the right direction.
thanks,
- Joel
| |