> because the P-state programmed by it at this point may
> very well be stale after getting out of the idle state, so instead of
> doing a full update at this point, it should force a low P-state on
> the way from idle.
Makes sense.
Paul has asked about the timer interupts, and here is some more info,
when there is no active load in system, the longest interval of 4
seconds between 2 timer interrupts comes from the kernel watchdog
for hardware/software lockup detector, and every CPU will have this
timer, which limits the maximum cpu idle duration to be 4 seconds.
> > ---
> >
> > diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
> > index d17b0a5ce6ac..e12688036725 100644
> > --- a/kernel/sched/idle.c
> > +++ b/kernel/sched/idle.c
> > @@ -258,15 +258,23 @@ static void cpuidle_idle_call(void)
> > *
> > * Called with polling cleared.
> > */
> > +DEFINE_PER_CPU(u64, last_util_update_time); /* in jiffies */
> > static void do_idle(void)
> > {
> > int cpu = smp_processor_id();
> > + u64 expire;
> >
> > /*
> > * Check if we need to update blocked load
> > */
> > nohz_run_idle_balance(cpu);
> >
> > + expire = __this_cpu_read(last_util_update_time) + HZ * 3;
> > + if (unlikely(time_is_before_jiffies((unsigned long)expire))) {
> > + cpufreq_update_util(this_rq(), 0);
>
> And quite frankly I'm not sure if running cpufreq_update_util() from
> here is safe.
I had that concern too :). Do you mean this is called when the local
irq is enabled, and could be interrupted causing some issue?
Thanks,
Feng
> > + __this_cpu_write(last_util_update_time, get_jiffies_64());
> > + }
> > +
> > /*
> > * If the arch has a polling bit, we maintain an invariant:
> > *
> >
