On Tue, 26 Feb 2019 at 23:08, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > On Tue, Feb 26, 2019 at 3:54 PM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > > > > 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! > > 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!? > > 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? Kind regards Uffe
