From: "Doug Smythies" <dsmythies@telus.net>
To: "'Rafael J. Wysocki'" <rjw@rjwysocki.net>
Cc: "'Rik van Riel'" <riel@surriel.com>,
"'Mike Galbraith'" <mgalbraith@suse.de>,
"'Thomas Gleixner'" <tglx@linutronix.de>,
"'Paul McKenney'" <paulmck@linux.vnet.ibm.com>,
"'Thomas Ilsche'" <thomas.ilsche@tu-dresden.de>,
"'Frederic Weisbecker'" <fweisbec@gmail.com>,
"'Linux PM'" <linux-pm@vger.kernel.org>,
"'Aubrey Li'" <aubrey.li@linux.intel.com>,
"'LKML'" <linux-kernel@vger.kernel.org>,
"'Peter Zijlstra'" <peterz@infradead.org>,
"'Doug Smythies'" <dsmythies@telus.net>
Subject: RE: [RFC/RFT][PATCH v3 0/6] sched/cpuidle: Idle loop rework
Date: Sun, 11 Mar 2018 16:02:14 -0700 [thread overview]
Message-ID: <000c01d3b98d$016eeb10$044cc130$@net> (raw)
In-Reply-To: v2lnemfac1Konv3GbegAC4
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
next prev parent reply other threads:[~2018-03-11 23:02 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-09 9:34 [RFC/RFT][PATCH v3 0/6] sched/cpuidle: Idle loop rework Rafael J. Wysocki
2018-03-09 9:36 ` [RFC/RFT][PATCH v3 1/6] time: tick-sched: Reorganize idle tick management code Rafael J. Wysocki
2018-03-09 9:38 ` [RFC/RFT][PATCH v3 2/6] sched: idle: Do not stop the tick upfront in the idle loop Rafael J. Wysocki
2018-03-09 9:39 ` [RFC/RFT][PATCH v3 3/6] sched: idle: Do not stop the tick before cpuidle_idle_call() Rafael J. Wysocki
2018-03-09 9:41 ` [RFC/RFT][PATCH v3 4/6] cpuidle: Return nohz hint from cpuidle_select() Rafael J. Wysocki
2018-03-09 9:46 ` [RFC/RFT][PATCH v3 5/6] sched: idle: Select idle state before stopping the tick Rafael J. Wysocki
2018-03-11 1:44 ` Frederic Weisbecker
2018-03-11 10:31 ` Rafael J. Wysocki
2018-03-09 9:49 ` [RFC/RFT][PATCH v3 6/6] cpuidle: menu: Refine idle state selection for running tick Rafael J. Wysocki
2018-03-09 15:19 ` [RFC/RFT][PATCH v3 0/6] sched/cpuidle: Idle loop rework Rik van Riel
2018-03-10 5:01 ` Mike Galbraith
2018-03-10 9:09 ` Rafael J. Wysocki
2018-03-10 7:41 ` Doug Smythies
2018-03-10 9:00 ` Rafael J. Wysocki
2018-03-10 16:07 ` Doug Smythies
2018-03-10 23:55 ` Rafael J. Wysocki
2018-03-11 7:43 ` Doug Smythies
2018-03-11 10:21 ` Rafael J. Wysocki
2018-03-11 10:34 ` Rafael J. Wysocki
2018-03-11 15:52 ` Doug Smythies
2018-03-11 23:02 ` Doug Smythies [this message]
2018-03-12 9:28 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='000c01d3b98d$016eeb10$044cc130$@net' \
--to=dsmythies@telus.net \
--cc=aubrey.li@linux.intel.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mgalbraith@suse.de \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=riel@surriel.com \
--cc=rjw@rjwysocki.net \
--cc=tglx@linutronix.de \
--cc=thomas.ilsche@tu-dresden.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).