[lkml]   [2018]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: [RFC/RFT][PATCH v3 0/6] sched/cpuidle: Idle loop rework
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".
>> 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:
>> 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:

... Doug

 \ /
  Last update: 2018-03-12 00:02    [W:0.120 / U:1.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site