From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Peter Zijlstra <peterz@infradead.org>,
Linux PM <linux-pm@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Frederic Weisbecker <fweisbec@gmail.com>,
Paul McKenney <paulmck@linux.vnet.ibm.com>,
Thomas Ilsche <thomas.ilsche@tu-dresden.de>,
Doug Smythies <dsmythies@telus.net>,
Rik van Riel <riel@surriel.com>,
Aubrey Li <aubrey.li@linux.intel.com>,
Mike Galbraith <mgalbraith@suse.de>,
LKML <linux-kernel@vger.kernel.org>
Subject: [RFC/RFT][PATCH v2 0/6] sched/cpuidle: Idle loop rework
Date: Tue, 06 Mar 2018 09:57:16 +0100 [thread overview]
Message-ID: <2067762.1uWBf5RSRc@aspire.rjw.lan> (raw)
Hi All,
Thanks a lot for the discussion so far!
Here's a new version of the series addressing some comments from the
discussion and (most importantly) replacing patches 4 and 5 with another
(simpler) patch.
The summary below still applies:
On Sunday, March 4, 2018 11:21:30 PM CET Rafael J. Wysocki wrote:
>
> The problem is that if we stop the sched tick in
> tick_nohz_idle_enter() and then the idle governor predicts short idle
> duration, we lose regardless of whether or not it is right.
>
> If it is right, we've lost already, because we stopped the tick
> unnecessarily. If it is not right, we'll lose going forward, because
> the idle state selected by the governor is going to be too shallow and
> we'll draw too much power (that has been reported recently to actually
> happen often enough for people to care).
>
> This patch series is an attempt to improve the situation and the idea
> here is to make the decision whether or not to stop the tick deeper in
> the idle loop and in particular after running the idle state selection
> in the path where the idle governor is invoked. This way the problem
> can be avoided, because the idle duration predicted by the idle governor
> can be used to decide whether or not to stop the tick so that the tick
> is only stopped if that value is large enough (and, consequently, the
> idle state selected by the governor is deep enough).
>
> The series tires to avoid adding too much new code, rather reorder the
> existing code and make it more fine-grained.
>
> Patch 1 prepares the tick-sched code for the subsequent modifications and it
> doesn't change the code's functionality (at least not intentionally).
>
> Patch 2 starts pushing the tick stopping decision deeper into the idle
> loop, but it is limited to do_idle() and tick_nohz_irq_exit().
>
> Patch 3 makes cpuidle_idle_call() decide whether or not to stop the tick
> and sets the stage for the changes in patch 6.
Patch 4 adds a bool pointer argument to cpuidle_select() and the ->select
governor callback allowing them to return a "nohz" hint on whether or not to
stop the tick to the caller.
Patch 5 reorders the idle state selection with respect to the stopping of the
tick and causes the additional "nohz" hint from cpuidle_select() to be used
for deciding whether or not to stop the tick.
Patch 6 cleans up the code to avoid running one piece of it twice in a row
in some cases.
And the two paragraphs below still apply:
> I have tested these patches on a couple of machines, including the very laptop
> I'm sending them from, without any obvious issues, but please give them a go
> if you can, especially if you have an easy way to reproduce the problem they
> are targeting. The patches are on top of 4.16-rc3 (if you need a git branch
> with them for easier testing, please let me know).
>
> The above said, this is just RFC, so no pets close to the machines running it,
> please, and I'm kind of expecting Peter and Thomas to tear it into pieces. :-)
Thanks,
Rafael
next reply other threads:[~2018-03-06 9:12 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-06 8:57 Rafael J. Wysocki [this message]
2018-03-06 9:02 ` [RFC/RFT][PATCH v2 1/6] time: tick-sched: Reorganize idle tick management code Rafael J. Wysocki
2018-03-07 23:18 ` Frederic Weisbecker
2018-03-08 9:22 ` Rafael J. Wysocki
2018-03-08 15:14 ` Frederic Weisbecker
2018-03-08 16:34 ` Rafael J. Wysocki
2018-03-08 17:00 ` Frederic Weisbecker
2018-03-06 9:02 ` [RFC/RFT][PATCH v2 2/6] sched: idle: Do not stop the tick upfront in the idle loop Rafael J. Wysocki
2018-03-07 23:39 ` Frederic Weisbecker
2018-03-08 9:05 ` Rafael J. Wysocki
2018-03-06 9:03 ` [RFC/RFT][PATCH v2 3/6] sched: idle: Do not stop the tick before cpuidle_idle_call() Rafael J. Wysocki
2018-03-06 9:05 ` [RFC/RFT][PATCH v2 4/6] cpuidle: Return nohz hint from cpuidle_select() Rafael J. Wysocki
2018-03-06 9:28 ` Rafael J. Wysocki
2018-03-06 10:06 ` [Update][RFC/RFT][PATCH " Rafael J. Wysocki
2018-03-06 9:10 ` [RFC/RFT][PATCH v2 5/6] sched: idle: Select idle state before stopping the tick Rafael J. Wysocki
2018-03-06 9:10 ` [RFC/RFT][PATCH v2 6/6] time: tick-sched: Avoid running the same code twice in a row Rafael J. Wysocki
2018-03-08 10:31 ` [RFC/RFT][PATCH v2 0/6] sched/cpuidle: Idle loop rework Mike Galbraith
2018-03-08 11:10 ` Rafael J. Wysocki
2018-03-08 13:40 ` Mike Galbraith
2018-03-09 9:58 ` Rafael J. Wysocki
2018-03-07 17:04 Doug Smythies
2018-03-07 22:11 ` Rafael J. Wysocki
2018-03-08 1:28 ` Doug Smythies
2018-03-08 15:18 ` Doug Smythies
2018-03-08 16:16 ` Rik van Riel
2018-03-08 16:36 ` Rafael J. Wysocki
2018-03-08 16:37 ` 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=2067762.1uWBf5RSRc@aspire.rjw.lan \
--to=rjw@rjwysocki.net \
--cc=aubrey.li@linux.intel.com \
--cc=dsmythies@telus.net \
--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=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).