On Tue, 1 Sep 2020 at 19:42, Peter Zijlstra firstname.lastname@example.org wrote:
On Tue, Sep 01, 2020 at 09:13:40AM -0700, Paul E. McKenney wrote:
On Tue, Sep 01, 2020 at 05:50:14PM +0200, email@example.com wrote:
On Tue, Sep 01, 2020 at 09:44:17AM -0600, Lina Iyer wrote:
> > > I could add RCU_NONIDLE for the calls to pm_runtime_put_sync_suspend() > > > and pm_runtime_get_sync() in psci_enter_domain_idle_state(). Perhaps > > > that's the easiest approach, at least to start with.
I think this would be nice. This should also cover the case, where PM domain power off notification callbacks call trace function internally. Right?
That's just more crap for me to clean up later :-(
trace_*_rcuidle() and RCU_NONIDLE() need to die, not proliferate.
Moving the idle-entry boundary further in is good in any number of ways. But experience indicates that no matter how far you move it, there will be something complex further in. Unless you are pushing it all the way into all the arch-specific code down as far as it can possibly go?
Not all; the simple cpuidle drivers should be good already. The more complicated ones need some help.
The patch provided earlier:
should allow the complicated drivers to take over and DTRT.
Don't get me wrong, I fully support your approach by moving the rcu_idle_enter() down as far as possible, but it seems to require more work than just adding a simple flag for the idle states.
Lots of cpuidle drivers are using CPU_PM notifiers (grep for cpu_pm_enter and you will see) from their idlestates ->enter() callbacks. And for those we are already calling rcu_irq_enter_irqson|off() in cpu_pm_notify() when firing them.
Kind regards Uffe