Messages in this thread | | | From | "Rafael J. Wysocki" <> | Subject | Re: [RFC/RFT][PATCH v3 0/6] sched/cpuidle: Idle loop rework | Date | Sun, 11 Mar 2018 11:21:36 +0100 |
| |
On Sunday, March 11, 2018 8:43:02 AM CET Doug Smythies wrote: > On 2018.03.10 15:55 Rafael J. Wysocki wrote: > >On Saturday, March 10, 2018 5:07:36 PM CET Doug Smythies wrote: > >> On 2018.03.10 01:00 Rafael J. Wysocki wrote: > > > ... [snip] ... > > > The information that they often spend more time than a tick > > period in state 0 in one go *is* relevant, though. > > > > > > That issue can be dealt with in a couple of ways and the patch below is a > > rather straightforward attempt to do that. The idea, basically, is to discard > > the result of governor prediction if the tick has been stopped alread and > > the predicted idle duration is within the tick range. > > > > Please try it on top of the v3 and tell me if you see an improvement. > > It seems pretty good so far. > See a new line added to the previous graph, "rjwv3plus". > > http://fast.smythies.com/rjwv3plus_100.png
OK, cool!
Below is a respin of the last patch which also prevents shallow states from being chosen due to interactivity_req when the tick is stopped.
You may also add a poll_idle() fix I've just posted:
https://patchwork.kernel.org/patch/10274595/
on top of this. It makes quite a bit of a difference for me. :-)
> I'll do another 100% load on one CPU test overnight, this time with > a trace.
Thanks!
| |