On Friday, September 23, 2016 03:44:23 PM Sai Gurrappadi wrote:

On 09/23/2016 03:06 PM, Peter Zijlstra wrote:> On Fri, Sep 23, 2016 at 02:49:47PM -0700, Sai Gurrappadi wrote:

quoted

quoted

When triaging a performance degradation of ~5% on some use cases between
our k3.18 and k4.4 trees, we found that the menu cpuidle governor on k4.4
was way more aggressive when requesting for deeper idle states. It would
often get it wrong though resulting in perf loss.

The menu governor tries to bias picking shallower idle states based on the
historical load on the CPU. The busier the CPU, the shallower the idle
state.

However, after commit "3289bdb sched: Move the loadavg code to a more

The normal quoting style is:

  3289bdb42988 ("sched: Move the loadavg code to a more obvious location")

Use at least 12 SHA1 characters, collisions on 7-8 char abbrevs have
already happened.

Also, that was more than a year ago, nobody noticed?

Ah, sorry. Will do next time.

quoted

quoted

obvious location", the load metric it looks at is rq->load.weight which is
the instantaneous se->load.weight sum for top level entities on the rq
which on idle entry is always 0 (for the common case at least) because
there is nothing on the cfs rq.

The previous metric the menu governor used was rq->cpu_load[0] which is a
snap shot of the weighted_cpuload at the previous load update point so it
isn't always 0 on idle entry.

Right, basically a 'random' number :)

Indeed. I never really understood how things worked with the cpu_load stuff
given how random it seemed.

Well, the choice seems to be between "better performance, but we don't really
know how we get that" and "more idle and we understand how it works".

Honestly, I prefer to understand how it works in the first place.

Of course, the fact that the metric used currently is (almost) always 0 is a
problem, but it doesn't seem like going back to the old one would be a huge
improvement either.

Thanks,
Rafael