All of lore.kernel.org
 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 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.