From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Alex Shi <alex.shi@linaro.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Linux PM <linux-pm@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Arjan van de Ven <arjan@linux.intel.com>,
Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency consideration
Date: Mon, 23 Jan 2017 13:50:25 +0100 [thread overview]
Message-ID: <20170123125025.GB2166@mai> (raw)
In-Reply-To: <58840B80.7000808@linaro.org>
On Sun, Jan 22, 2017 at 09:31:44AM +0800, Alex Shi wrote:
>
> >Yeah, that could be problematic. The code snippet gives the general idea but it
> >could be changed by for example by a flag telling the cpus when they enter idle
> >to update their state_count. Or something like that.
>
> Yes, this idea could be helpful.
>
> But since the idle path isn't a hot path. and a few memory access won't cost
> a lot. So I doubt if the benefit could be measurable.
It won't be measurable, as well as reading the cpu device latency before
checking the latency req is zero, but it makes sense.
The idle routine is not a hot path but a very special place where the interrupt
are disabled, the rcu is not usable, tick is disabled etc ...
Perhaps it is not a problem for the moment, but it is probably worth to mention that
using API from other subsystems in the idle select path could be problematic
and perhaps it is time to think about another approach for the future.
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
next prev parent reply other threads:[~2017-01-23 12:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-12 13:27 [PATCH v2 0/3] per cpu resume latency Alex Shi
2017-01-12 13:27 ` [PATCH 1/3] cpuidle/menu: stop seeking deeper idle if current state is too deep Alex Shi
2017-01-12 13:27 ` [PATCH v2 2/3] cpu: expose pm_qos_resume_latency for each cpu Alex Shi
2017-01-17 10:23 ` Daniel Lezcano
2017-01-19 8:18 ` Alex Shi
2017-01-12 13:27 ` [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency consideration Alex Shi
2017-01-12 20:03 ` Rik van Riel
2017-01-16 1:11 ` Alex Shi
2017-01-17 9:38 ` Daniel Lezcano
2017-01-19 9:25 ` Alex Shi
2017-01-19 10:21 ` Daniel Lezcano
2017-01-19 21:43 ` Rafael J. Wysocki
2017-01-20 8:35 ` Alex Shi
2017-01-20 10:54 ` Daniel Lezcano
2017-01-22 1:31 ` Alex Shi
2017-01-23 12:50 ` Daniel Lezcano [this message]
2017-01-23 14:58 ` Alex Shi
[not found] <1483630187-29622-1-git-send-email-alex.shi@linaro.org>
2017-01-05 15:29 ` Alex Shi
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=20170123125025.GB2166@mai \
--to=daniel.lezcano@linaro.org \
--cc=alex.shi@linaro.org \
--cc=arjan@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=rafael.j.wysocki@intel.com \
--cc=rafael@kernel.org \
--cc=riel@redhat.com \
--cc=ulf.hansson@linaro.org \
--cc=vincent.guittot@linaro.org \
/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).