Messages in this thread | | | From | "Doug Smythies" <> | Subject | RE: [RFC/RFT][PATCH v3 0/6] sched/cpuidle: Idle loop rework | Date | Sun, 11 Mar 2018 16:02:14 -0700 |
| |
On 2018.03.11 08:52 Doug Smythies wrote: > On 2018.03.11 03:22 Rafael J. Wysocki wrote: >> 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 will add and test, but I already know from testing previous versions > of this patch, from Rik van Riel and myself, that the results will be > awesome.
And the results are indeed awesome.
A four hour 100% load on one CPU test was run, with trace, however there is nothing to report, as everything is great.
The same graph as the last couple of days, with a new line added for V3 + the respin of patch 7 of 6 + the poll-idle fix, called rjwv3pp, is here:
http://fast.smythies.com/rjwv3pp_100.png
... Doug
| |