From: "Li, Aubrey" <aubrey.li@linux.intel.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>, Aubrey Li <aubrey.li@intel.com>
Cc: tglx@linutronix.de, peterz@infradead.org, len.brown@intel.com,
ak@linux.intel.com, tim.c.chen@linux.intel.com,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 4/8] tick/nohz: keep tick on for a fast idle
Date: Mon, 16 Oct 2017 11:26:11 +0800 [thread overview]
Message-ID: <5beefd1a-2792-c371-3bb8-8ee2a6574020@linux.intel.com> (raw)
In-Reply-To: <4523111.uMcC96MW3N@aspire.rjw.lan>
On 2017/10/14 8:51, Rafael J. Wysocki wrote:
> On Saturday, September 30, 2017 9:20:30 AM CEST Aubrey Li wrote:
>> If the next idle is expected to be a fast idle, we should keep tick
>> on before going into idle
>>
>> Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com>
>
> This also can be merged with the previous patch (and the [2/8]) IMO.
>
okay, will merge in the next version.
>> ---
>> drivers/cpuidle/cpuidle.c | 14 ++++++++++++++
>> include/linux/cpuidle.h | 2 ++
>> kernel/time/tick-sched.c | 4 ++++
>> 3 files changed, 20 insertions(+)
>>
>> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
>> index ef6f7dd..6cb7e17 100644
>> --- a/drivers/cpuidle/cpuidle.c
>> +++ b/drivers/cpuidle/cpuidle.c
>> @@ -370,6 +370,20 @@ void cpuidle_predict(void)
>> }
>>
>> /**
>> + * cpuidle_fast_idle - predict whether or not the coming idle is a fast idle
>> + * This function can be called in irq exit path, make it as soon as possible
>> + */
>> +bool cpuidle_fast_idle(void)
>> +{
>> + struct cpuidle_device *dev = cpuidle_get_device();
>> +
>> + if (!dev)
>> + return false;
>> +
>> + return dev->idle_stat.fast_idle;
>
> return dev && dev->idle_stat.fast_idle;
Thanks!
>>
>> @@ -916,6 +917,9 @@ static bool can_stop_idle_tick(int cpu, struct tick_sched *ts)
>> return false;
>> }
>>
>> + if (cpuidle_fast_idle())
>> + return false;
>> +
>> return true;
>
> return !cpuidle_fast_idle();
And thanks!
>
>> }
>>
>>
>
> And IMO there is quite a bit too much marketing in the "fast_idle" name,
> as it seems all about avoiding to stop the tick if the predicted idle
> duration is short enough.
>
okay, and what's your suggestion? :)
I'll try to move quiet_vmstat() into the normal idle branch if this patch series
are reasonable. Is fast_idle a good indication for it?
Thanks,
-Aubrey
next prev parent reply other threads:[~2017-10-16 3:26 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-30 7:20 [RFC PATCH v2 0/8] Introduct cpu idle prediction functionality Aubrey Li
2017-09-30 7:20 ` [RFC PATCH v2 1/8] cpuidle: menu: extract " Aubrey Li
2017-10-14 0:26 ` Rafael J. Wysocki
2017-10-16 2:46 ` Li, Aubrey
2017-09-30 7:20 ` [RFC PATCH v2 2/8] cpuidle: record the overhead of idle entry Aubrey Li
2017-10-14 0:35 ` Rafael J. Wysocki
2017-10-16 3:11 ` Li, Aubrey
2017-10-17 0:05 ` Rafael J. Wysocki
2017-10-17 7:04 ` Li, Aubrey
2017-09-30 7:20 ` [RFC PATCH v2 3/8] cpuidle: add a new predict interface Aubrey Li
2017-10-14 0:45 ` Rafael J. Wysocki
2017-10-16 8:04 ` Li, Aubrey
2017-10-14 1:27 ` Rafael J. Wysocki
2017-10-16 9:52 ` Li, Aubrey
2017-09-30 7:20 ` [RFC PATCH v2 4/8] tick/nohz: keep tick on for a fast idle Aubrey Li
2017-10-14 0:51 ` Rafael J. Wysocki
2017-10-16 3:26 ` Li, Aubrey [this message]
2017-10-16 4:45 ` Mike Galbraith
2017-10-16 5:34 ` Li, Aubrey
2017-10-16 6:25 ` Mike Galbraith
2017-10-16 6:31 ` Li, Aubrey
2017-09-30 7:20 ` [RFC PATCH v2 5/8] timers: keep sleep length updated as needed Aubrey Li
2017-10-14 0:56 ` Rafael J. Wysocki
2017-10-16 6:46 ` Li, Aubrey
2017-10-16 23:58 ` Rafael J. Wysocki
2017-10-17 6:10 ` Li, Aubrey
2017-09-30 7:20 ` [RFC PATCH v2 6/8] cpuidle: make fast idle threshold tunable Aubrey Li
2017-10-14 0:59 ` Rafael J. Wysocki
2017-10-16 6:00 ` Li, Aubrey
2017-10-17 0:01 ` Rafael J. Wysocki
2017-10-17 6:12 ` Li, Aubrey
2017-09-30 7:20 ` [RFC PATCH v2 7/8] cpuidle: introduce irq timing to make idle prediction Aubrey Li
2017-10-14 1:01 ` Rafael J. Wysocki
2017-10-16 6:03 ` Li, Aubrey
2017-09-30 7:20 ` [RFC PATCH v2 8/8] cpuidle: introduce run queue average idle " Aubrey Li
2017-10-14 1:02 ` Rafael J. Wysocki
2017-10-14 1:14 ` [RFC PATCH v2 0/8] Introduct cpu idle prediction functionality Rafael J. Wysocki
2017-10-16 7:44 ` Li, Aubrey
2017-10-17 0:07 ` Rafael J. Wysocki
2017-10-17 7:32 ` Li, Aubrey
2017-11-30 1:00 ` Li, Aubrey
2017-11-30 1: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=5beefd1a-2792-c371-3bb8-8ee2a6574020@linux.intel.com \
--to=aubrey.li@linux.intel.com \
--cc=ak@linux.intel.com \
--cc=aubrey.li@intel.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=rjw@rjwysocki.net \
--cc=tglx@linutronix.de \
--cc=tim.c.chen@linux.intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.