[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <001801d3b90c$99232600$cb697200$@net>
Date: Sat, 10 Mar 2018 23:43:02 -0800
From: "Doug Smythies" <dsmythies@...us.net>
To: "'Rafael J. Wysocki'" <rjw@...ysocki.net>
Cc: "'Rik van Riel'" <riel@...riel.com>,
"'Mike Galbraith'" <mgalbraith@...e.de>,
"'Thomas Gleixner'" <tglx@...utronix.de>,
"'Paul McKenney'" <paulmck@...ux.vnet.ibm.com>,
"'Thomas Ilsche'" <thomas.ilsche@...dresden.de>,
"'Frederic Weisbecker'" <fweisbec@...il.com>,
"'Linux PM'" <linux-pm@...r.kernel.org>,
"'Aubrey Li'" <aubrey.li@...ux.intel.com>,
"'LKML'" <linux-kernel@...r.kernel.org>,
"'Peter Zijlstra'" <peterz@...radead.org>,
"Doug Smythies" <dsmythies@...us.net>
Subject: RE: [RFC/RFT][PATCH v3 0/6] sched/cpuidle: Idle loop rework
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
I'll do another 100% load on one CPU test overnight, this time with
a trace.
... Doug
Powered by blists - more mailing lists