RE: [PATCH] cpuidle: Allow menu governor to enter deeper sleep states after some time

Hi Thomas,

Thanks for your follow up and detailed information.
I have continued to work on this during these 2+ weeks,
but was unable to get to the root cause.

On 2017.11.07 15:04 Thomas Ilsche wrote:

thanks to your detailed description I was able to reproduce and track down the
issue on one of our systems with a similar processor. The effect is similar, the
core stays in a shallow sleep state for too long.
This is also amplified on a system with little background noise where a core
can stay in C0 for seconds.

Agreed.

But the cause / trigger is different.

Agreed.

By my observation with many perf probes,
the next timer is preventing a deep sleep, also overriding the anti-poll
mechanism.

Agreed, but haven't been able to figure out why. Yu's e-mail on this point
is very interesting.

This immediate (usually 1-3 us) timer can be both tick_sched_timer and
watchdog_timer_fn. The timers actually do happen and run, however poll_idle
directly resumes after the interrupt - there is no need_resched(). The menu
governor assumes that a timer will trigger another menu_select, but it does not.
Neither does our fallback timer - so the mitigation.

Agreed.

I made a hack[1] to stop poll_idle after timer_expires which prevents the issue
in my tests.

I did a similar test with the same results. In my case I just used an old
proposed patch from Rik van Riel [2] (well, rebased to current).

However, I still wanted to understand why this issue occurs in the first
place, because and as far as could tell, it shouldn't.
This is where I got stuck.

...[snip]...

... Doug

[2] https://marc.info/?l=linux-pm&m=145834176720176&w=2