All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Shi <alex.shi@linaro.org>
To: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Vincent Guittot <vincent.guittot@linaro.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	open list <linux-kernel@vger.kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Arjan van de Ven <arjan@linux.intel.com>,
	Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH 4/4] cpuidle/menu: add per cpu pm_qos_resume_latency consideration
Date: Fri, 23 Sep 2016 12:58:40 +0800	[thread overview]
Message-ID: <57E4B680.6080605@linaro.org> (raw)
In-Reply-To: <fdf44e20-c7a1-5e2b-22e8-36852bf2c02a@intel.com>



On 09/23/2016 09:36 AM, Rafael J. Wysocki wrote:
> On 9/14/2016 10:28 AM, Vincent Guittot wrote:
>> Hi Rafael,
>>
>> On 14 September 2016 at 00:10, Rafael J. Wysocki <rjw@rjwysocki.net>
>> wrote:
>>> On Tuesday, September 13, 2016 10:02:49 PM Alex Shi wrote:
>>>> Hi Daniel & Rafael,
>>>>
>>>> Any comments on this patch?
>>> I actually am not sure about the whole series.
>>>
>>> I know your motivation, but honestly the changes here may not be the
>>> best way
>>> to achieve what you need.

Is there some idea for better way?

>>>
>>> You may think that the changes are trivial, but in fact they are
>>> not.  There
>>> are side effects and I'm not sure about the resulting user space
>>> interface
>>> at all.

What's concern is abuse of user interface? If the request come from user
level, is there other ways to set a value for this?


>> This patchset has got 2 parts:
>> - one part is about taking into account per-device resume latency
>> constraint when selecting the idle state of a CPU. This value can
>> already be set by kernel (even if it's probably not done yet) but this
>> constraint is never taken into account
>> - the other part is about exposing the resume latency to userspace.
>> This part might raise more discussion but I see one example that could
>> take advantage of this. When you have several clusters of CPUs and you
>> want to dedicate some CPUs  to latency sensitive activity and prevent
>> deep sleep  state on these CPUs but you want to let the other CPUs
>> using all C-state
> 
> The first very basic question about this I have is whether or not the
> device PM QoS mechanism is suitable for the task at hand at all.
> 
> It certainly hasn't been invented with it in mind.
> 

Look though the device PM QoS, this kind of usage seems sensible. So why
not?

Regards
Alex

  reply	other threads:[~2016-09-23  4:58 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-25  8:42 [PATCH 1/4] cpu: clean up register_cpu func Alex Shi
2016-08-25  8:42 ` Alex Shi
2016-08-25  8:42 ` [PATCH 2/4] cpu: expose pm_qos_resume_latency for each cpu Alex Shi
2016-08-25  8:42   ` Alex Shi
2016-08-31 10:45   ` Alex Shi
2016-08-31 13:18   ` Greg Kroah-Hartman
2016-09-01  3:39     ` Alex Shi
2016-09-01  3:45       ` Alex Shi
2016-09-01  3:50   ` Alex Shi
2016-09-01  9:26     ` Ulf Hansson
2016-09-13  1:04       ` Alex Shi
2016-09-13  7:17         ` Ulf Hansson
2016-09-13 13:57     ` Alex Shi
2016-08-25  8:42 ` [PATCH 3/4] cpuidle/menu: stop seeking deeper idle if current state is too deep Alex Shi
2016-08-25  8:42   ` Alex Shi
2016-08-31 10:45   ` Alex Shi
2016-09-13 14:01   ` Alex Shi
2016-08-25  8:42 ` [PATCH 4/4] cpuidle/menu: add per cpu pm_qos_resume_latency consideration Alex Shi
2016-08-25  8:42   ` Alex Shi
2016-08-31 10:46   ` Alex Shi
2016-09-13 14:02   ` Alex Shi
2016-09-13 22:10     ` Rafael J. Wysocki
2016-09-14  8:28       ` Vincent Guittot
2016-09-23  1:36         ` Rafael J. Wysocki
2016-09-23  4:58           ` Alex Shi [this message]
2016-08-31 10:45 ` [PATCH 1/4] cpu: clean up register_cpu func Alex Shi
2016-08-31 13:17   ` Greg Kroah-Hartman
  -- strict thread matches above, loose matches on Subject: below --
2016-08-19  8:25 Alex Shi
2016-08-19  8:25 ` [PATCH 4/4] cpuidle/menu: add per cpu pm_qos_resume_latency consideration 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=57E4B680.6080605@linaro.org \
    --to=alex.shi@linaro.org \
    --cc=arjan@linux.intel.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=rafael.j.wysocki@intel.com \
    --cc=riel@redhat.com \
    --cc=rjw@rjwysocki.net \
    --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 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.