Thread (19 messages) 19 messages, 2 authors, 2019-02-27

Re: [PATCH v11 7/8] cpuidle: Pre-store next timer/tick before selecting an idle state

From: "Rafael J. Wysocki" <rafael@kernel.org>
Date: 2019-02-26 23:41:08
Also in: linux-arm-msm, linux-pm, lkml

On Wed, Feb 27, 2019 at 12:16 AM Ulf Hansson [off-list ref] wrote:
On Tue, 26 Feb 2019 at 23:08, Rafael J. Wysocki [off-list ref] wrote:
quoted
On Tue, Feb 26, 2019 at 3:54 PM Ulf Hansson [off-list ref] wrote:
quoted
A common piece of data used by cpuidle governors, is the information about
when the next timer/tick is going to fire. Rather than having each governor
calling tick_nohz_get_next_timer|hrtimer() separately, let's consolidate
the code by calling these functions before invoking the ->select() callback
of the governor - and store the output data in the struct cpuidle_device.
That misses the point IMO.

You don't need to store two values in struct cpuidle_device, but just
one, and not before running ->select(), but before invoking the
driver's ->enter() callback.
Okay! Thanks for letting me know!
quoted
At that point, the decision on whether or not to stop the scheduler
tick has been made already and it should be sufficient to store the
return value of tick_nohz_get_next_hrtimer() introduced by patch
[3/8], because that value represents the next timer regardless of what
has been decided with respect to the tick.
Just to make sure I get this correctly, because it seems like I have
missed a few points here....

If we decided to keep the tick running, then
tick_nohz_get_next_hrtimer() gives the next tick or the next hrtimer,
whatever that comes first. There are no other timer that can expire
earlier than this, right!?

If we decided to stop the tick, then tick_nohz_get_next_hrtimer() will
give us the next hrtimer. Again, then there are no other timer that
can't expire earlier than this, right!?
Right in both cases.

IOW, that is the event that will wake up the CPU unless any other
(non-timer) interrupts (or equivalent events) occur in the meantime.
quoted
And you won't need the tick_nohz_get_next_timer() any more then.
Alright, this kind of brings this hole thing back closer to v10 - and
then we should stick to use tick_nohz_get_sleep_length() as is for the
cpuidle governors. That is what you are saying?
For the menu and teo governors - yes.  IMO
tick_nohz_get_sleep_length() is as good as it gets in there.

Cheers,
Rafael

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help