linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: mark gross <markgross@thegnar.org>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: markgross@thegnar.org, linux-pm@lists.linux-foundation.org,
	Antti P Miettinen <amiettinen@nvidia.com>,
	cpufreq@vger.kernel.org
Subject: Re: [linux-pm] [PATCH v2 0/8] RFC: CPU frequency min/max as PM QoS params
Date: Thu, 19 Jan 2012 08:41:44 -0800	[thread overview]
Message-ID: <20120119164144.GA8757@mgross-G62> (raw)
In-Reply-To: <201201190024.27022.rjw@sisk.pl>

On Thu, Jan 19, 2012 at 12:24:26AM +0100, Rafael J. Wysocki wrote:
> On Wednesday, January 18, 2012, mark gross wrote:
> > On Mon, Jan 16, 2012 at 10:38:57PM +0100, Rafael J. Wysocki wrote:
> > > Hi,
> > > 
> > > On Monday, January 16, 2012, Antti P Miettinen wrote:
> > > > [did not reach linux-pm as I sent to wrong address, sorry for
> > > > duplicates]
> > > > 
> > > > The inspiration for this patch series is the N9 CPU frequency boost
> > > > upon input events:
> > > > 
> > > > http://www.spinics.net/lists/cpufreq/msg00667.html
> > > > 
> > > > and the related changes in git://codeaurora.org/kernel/msm.git tree.
> > > > Those patches modify the ondemand cpufreq governor. This patch series
> > > > adds minimum and maximum CPU frequency as PM QoS parameters and
> > > > modifies the cpufreq core to enforce the PM QoS limits.
> > > 
> > > If that hasn't been clear enough so far, I'm still not convinced that using
> > > PM QoS for that is a good idea.
> > > 
> > > First off, frequency as a unit of throughput is questionable to say the least,
> > > because it isn't portable from one system to another.  Moreover, even on a
> > > given system it isn't particularly clear what the exact correspondence
> > > between frequency and throughput actually is.
> > 
> > You are right.  The notion of throughput of a CPU is really hard to
> > quantify.  Perhaps not using the term "throughput" would help?
> 
> Yes, it would.
> 
> > The base issue I see, the Intel platform, is needing is that sometimes
> > we need to block the lowest P-states that the ondemand governor goes for
> > because those P-states result in media / graphics workloads dropping
> > frames.  However; GPU intensive workloads do not stress the CPU so the
> > ondemand governor goes for the low p-state.
> > 
> > I could use some way of constraining the PM-throttling of the
> > cpu-freq that can be hit from kernel or user mode.  So the graphics
> > driver can dynamically adjust the constraint request on the cpufreq
> > subsystem.
> > 
> > It is problematic that any driver requesting a given frequency request
> > is not portable across ISA's or even processor families in the same ISA.
> > But, maybe such a driver should use a module parameter to work around
> > this lack of portability?
> 
> Well, it seems to me that we're trying to add a backdoor to the (apparently
> inadequate) governors here.  Arguably, the governors should be able to
> make the right decisions on the basis of the information they receive
> through their own interfaces.

the failings of governors to have the information needed is why pm_qos
was created in the first place.  It can be seen as a limitation on the
governor from some perspectives.  But, I like to think of if as updating
existing governors to account for new use case requirements as hardware
get bigger power management / performance dynamic ranges.


> > > Second, it's not particularly clear what the meaning of the "min" frequency
> > > is supposed to be in terms of throughput.
> > 
> > It should mean "please cpufreq do not put the cpu into a state where its
> > clock runs slower than min".  I don't think we should talk about it as
> > throughput because thats not what the cpufreq controls.
> 
> Perhaps we need a new cpufreq governor that would take use PM QoS internally
> to store requests from different sources, but that would work on a per-CPU
> basis (not globally) and would provide a new interface for user space?
> 

I don' think we need a new cpufreq governor, the parts of this patchset
that I agree with evolve the governor to account for pm-qos requests
but, globally for all cpu's.

Hmm, your right this patch set is global in its request and not
"per-cpu".  I need to think on that.  Making it per-cpu would likely
infer we need to make the qos request per cpu as well.  

Do you think it needs to be per-cpu?  (I'm starting to think "yes" it
does)

How do we scale the pm_qos ABI to support per/cpu?  (maybe we don't
export those types of qos classes to the user mode?)

--mark


  parent reply	other threads:[~2012-01-19 16:41 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-16  6:59 [PATCH v2 0/8] RFC: CPU frequency min/max as PM QoS params Antti P Miettinen
2012-01-16  6:59 ` [PATCH v2 1/8] PM QoS: Simplify PM QoS expansion/merge Antti P Miettinen
2012-01-16 21:22   ` Rafael J. Wysocki
2012-01-18  2:50     ` mark gross
2012-01-16  6:59 ` [PATCH v2 2/8] PM QoS: Add CPU frequency minimum as PM QoS param Antti P Miettinen
2012-01-16  6:59 ` [PATCH v2 3/8] cpufreq: Export user_policy min/max Antti P Miettinen
2012-01-16  6:59 ` [PATCH v2 4/8] cpufreq: Preserve sysfs min/max request Antti P Miettinen
2012-01-16  6:59 ` [PATCH v2 5/8] cpufreq: Enforce PM QoS minimum limit Antti P Miettinen
2012-01-16  6:59 ` [PATCH v2 6/8] input: CPU frequency booster Antti P Miettinen
2012-01-16  7:00 ` [PATCH v2 7/8] PM QoS: Add CPU frequency maximum as PM QoS param Antti P Miettinen
2012-01-16  7:00 ` [PATCH v2 8/8] cpufreq: Enforce PM QoS maximum frequency Antti P Miettinen
2012-01-16 21:38 ` [PATCH v2 0/8] RFC: CPU frequency min/max as PM QoS params Rafael J. Wysocki
2012-01-17  6:14   ` Antti P Miettinen
2012-01-17  6:25     ` [linux-pm] " Mansoor, Illyas
2012-01-17  9:54       ` Antti P Miettinen
2012-01-17 21:27     ` [linux-pm] " Rafael J. Wysocki
2012-01-18  7:52       ` Antti P Miettinen
2012-01-18 23:10         ` [linux-pm] " Rafael J. Wysocki
2012-01-19  6:41           ` Antti P Miettinen
2012-01-18  3:13   ` mark gross
2012-01-18  8:15     ` Antti P Miettinen
2012-01-18 23:16       ` [linux-pm] " Rafael J. Wysocki
2012-01-18 23:24     ` Rafael J. Wysocki
2012-01-19  6:49       ` Antti P Miettinen
2012-01-19 22:40         ` [linux-pm] " Rafael J. Wysocki
2012-01-22  9:55           ` Antti P Miettinen
2012-01-19 16:41       ` mark gross [this message]
2012-01-19 19:48         ` Antti P Miettinen
2012-01-19 22:15           ` [linux-pm] " Rafael J. Wysocki
2012-01-22 10:35             ` Antti P Miettinen
2012-01-22 23:43               ` [linux-pm] " Rafael J. Wysocki
2012-02-02  6:06                 ` Antti P Miettinen
2012-02-08  8:49                   ` Per CPU frequency constraints (was Re: [PATCH v2 0/8] RFC: CPU frequency min/max as PM QoS params) Antti P Miettinen
2012-01-19 23:36         ` [linux-pm] [PATCH v2 0/8] RFC: CPU frequency min/max as PM QoS params Rafael J. Wysocki
2012-01-18  3:44 ` mark gross
2012-01-18 20:22   ` Antti P Miettinen

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=20120119164144.GA8757@mgross-G62 \
    --to=markgross@thegnar.org \
    --cc=amiettinen@nvidia.com \
    --cc=cpufreq@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=rjw@sisk.pl \
    /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).