Re: [RFC] cpuidle: menu: nearby timer use lightest state; allow state 0 to be disabled

[Nicholas Piggin <npiggin@gmail.com>]

On Wed, 31 May 2017 02:26:31 +1000
Nicholas Piggin <npiggin@gmail.com> wrote:

> I've found the menu driver does not allow state0 to properly be disabled
> because of all this poll logic selecting the first state and then trying
> to iterate over subsequent states. Ripping most of that out and simplifying
> it solved that issue but raised more questions about polling logic.
> 
> Firstly polling logic is there only on architectures which define
> ARCH_HAS_CPU_RELAX, which is only x86. Seems like if we think a
> timer is so close that no powersave should be done, then surely just
> picking the lightest mode (whether that is polling or something else)
> would be best.
> 
> But looking further into it, it seems maybe like some x86 hack (as
> the comments and changelog in 7884084f3bcc and subsequent attempts to
> work around Atom and broken firmware suggests). I would have thought
> such broken hard/firmware should get workarounds applied to fix the
> state values rather than add such logic?
> 
> On the other hand, if (CPUIDLE_DRIVER_STATE_START > 0) is shorthand for
> if (x86 hacks), that's fine I'm happy to leave that alone and just work
> with the else parts...
> 
> This is just a draft, but it does what I want at least with regard to
> disabling state0 for testing.

Ping, any thoughts on these issues?

Thanks,
Nick