Re: [PATCH 0/3] cpuidle: updates related to tick_broadcast_enter() failures

[Daniel Lezcano]

On 05/12/2015 01:31 AM, Rafael J. Wysocki wrote:
> On Monday, May 11, 2015 07:40:41 PM Daniel Lezcano wrote:
> > On 05/10/2015 01:15 AM, Rafael J. Wysocki wrote:
> > > On Saturday, May 09, 2015 10:33:05 PM Rafael J. Wysocki wrote:
> > > > On Saturday, May 09, 2015 10:11:41 PM Rafael J. Wysocki wrote:
> > > > > On Saturday, May 09, 2015 11:19:16 AM Preeti U Murthy wrote:
> > > > > > Hi Rafael,
> > > > > >
> > > > > > On 05/08/2015 07:48 PM, Rafael J. Wysocki wrote:
> > > > >
> > > > > [cut]
> > > > >
> > > > > > > > +	/* Take note of the planned idle state. */
> > > > > > > > +	idle_set_state(smp_processor_id(), target_state);
> > > > > > >
> > > > > > > And I wouldn't do this either.
> > > > > > >
> > > > > > > The behavior here is pretty much as though the driver demoted the state chosen
> > > > > > > by the governor and we don't call idle_set_state() again in those cases.
> > > > > >
> > > > > > Why is this wrong?
> > > > >
> > > > > It is not "wrong", but incomplete, because demotions done by the cpuidle driver
> > > > > should also be taken into account in the same way.
> > > > >
> > > > > But I'm seeing that the recent patch of mine that made cpuidle_enter_state()
> > > > > call default_idle_call() was a mistake, because it might confuse find_idlest_cpu()
> > > > > significantly as to what state the CPU is in.  I'll drop that one for now.
> > > >
> > > > OK, done.
> > > >
> > > > So after I've dropped it I think we need to do three things:
> > > > (1) Move the idle_set_state() calls to cpuidle_enter_state().
> > > > (2) Make cpuidle_enter_state() call default_idle_call() again, but this time
> > > >       do that *before* it has called idle_set_state() for target_state.
> > > > (3) Introduce demotion as per my last patch.
> > > >
> > > > Let me cut patches for that.
> > >
> > > Done as per the above and the patches follow in replies to this messge.
> > >
> > > All on top of the current linux-next branch of the linux-pm.git tree.
> >
> > IMO the resulting code is more and more confusing.
>
> Why is it confusing?
>
> What part of it is confusing?
>
> Patches [1-2/3] simply replace https://patchwork.kernel.org/patch/6326761/
> and I'm not sure why that would be confusing.
>
> Patch [3/3] simply causes cpuidle_enter_state() to pick up a more suitable
> state if tick_broadcast_enter() fails instead of returning an error code
> in that case.  What exactly is confusing in that?
>
> > Except I miss something, the tick_broadcast_enter can fail only if the
> > local timer of the current cpu is used as a broadcast timer (which is
> > the case today for PPC only).
>
> well, why does this matter?
>
> > The correct fix would be to tie this local timer with the cpu power
> > domain and disable the idle state powering down this domain like it was
> > done for the renesas cpuidle driver.
> >
> > IOW, the cpu power domain is in use (because of its local timer), so we
> > shouldn't shut it down.
> >
> > No ?
>
> Sorry, I'm not sure what you're talking about.
>
> The problem at hand is that tick_broadcast_enter() can fail and we need to
> handle that.  If we can prevent it from ever failing, that would be awesome,
> but quite honestly I don't see how to do that ATM.

Ok, sorry. Let me clarify.

You did a mechanism two years ago with pm_genpd_attach_cpuidle and 
power_on/off. That disables a cpuidle state when a power domain is in use.

The idea I was proposing is to reuse this approach.

The logic is:

"The local timer is in use, this idle state power downs this timer, then 
disable it".

So it is when the broadcast timer is 'bound_on' a cpu, we disable the 
idle states. That could be done via a loop looking for the TIMER_STOP 
flag or via the power domain.

Hence the cpuidle_select will never return a state which powers downs 
the local cpu (because they are disabled) and tick_broadcast_enter can't 
fail because it is never called.

Does it make more sense ?

> > I am aware this is not easily fixable because the genpd framework is
> > incomplete and has some restrictions but I believe it is worth to have a
> > discussion. Add Kevin and Ulf in Cc.
>
> So I'm going to queue up these patches for 4.2 and we can have a discussion
> just fine regardless.



--
 <http://www.linaro.org/> Linaro.org â Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/