Re: pm qos infrastructure and interface

Re: pm qos infrastructure and interface

[Andrew Morton]

On Thu, 4 Oct 2007 14:51:39 -0700 Mark Gross <mgross@linux.intel.com> wrote:

> The following patch is a generalization of the latency.c implementation
> done by Arjan last year.  It provides infrastructure for more than one
> parameter, and exposes a user mode interface for processes to register
> pm_qos expectations of processes.
> 
> 
> This interface provides a kernel and user mode interface for registering
> performance expectations by drivers, subsystems and user space
> applications on one of the parameters.
> 
> Currently we have {cpu_dma_latency, network_latency, network_throughput}
> as the initial set of pm_qos parameters.
> 
> The infrastructure exposes multiple misc device nodes one per
> implemented parameter.  The set of parameters implement is defined by
> pm_qos_power_init() and pm_qos_params.h.  This is done because having
> the available parameters being runtime configurable or changeable from a
> driver was seen as too easy to abuse.

I'm a bit surprised that this change appears to have no configurability.
If one has set CONFIG_PM=n (for example), shouldn't it all go away?

Re: pm qos infrastructure and interface

[Mark Gross]

On Wed, Oct 10, 2007 at 10:17:04PM -0700, Andrew Morton wrote:
> On Thu, 4 Oct 2007 14:51:39 -0700 Mark Gross <mgross@linux.intel.com> wrote:
> 
> > The following patch is a generalization of the latency.c implementation
> > done by Arjan last year.  It provides infrastructure for more than one
> > parameter, and exposes a user mode interface for processes to register
> > pm_qos expectations of processes.
> > 
> > 
> > This interface provides a kernel and user mode interface for registering
> > performance expectations by drivers, subsystems and user space
> > applications on one of the parameters.
> > 
> > Currently we have {cpu_dma_latency, network_latency, network_throughput}
> > as the initial set of pm_qos parameters.
> > 
> > The infrastructure exposes multiple misc device nodes one per
> > implemented parameter.  The set of parameters implement is defined by
> > pm_qos_power_init() and pm_qos_params.h.  This is done because having
> > the available parameters being runtime configurable or changeable from a
> > driver was seen as too easy to abuse.
> 
> I'm a bit surprised that this change appears to have no configurability.
> If one has set CONFIG_PM=n (for example), shouldn't it all go away?

We considered that as an option but as latency.c didn't offer it I
didn't either.  

I could see the user mode interface portion of the implementation be
made as a compile time option but the kernel infrastructure will
continue to be needed by at least cpu-idel, pcm_native.c and ipw2100.

You know it could make sense to have the user mode interface part of the
patch as configurable or a build time dependent of sysfs and misc device
support for the linux-tiny guys.  Is it practical to make a linux-tiny
without the sysfs infrastructure needed to make a misc device?  I'll ask
on the linux-tiny list.

--mgross

Re: pm qos infrastructure and interface

[Arjan van de Ven]

On Wed, 10 Oct 2007 22:17:04 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:

> I'm a bit surprised that this change appears to have no
> configurability. If one has set CONFIG_PM=n (for example), shouldn't
> it all go away?

I suppose it's a matter of taste, but at least personally I believe that
userspace exposed ABI's shouldn't be configurable as a starting point
(if the code delta is 100's of kilobytes it's a different topic); what
point is talking about a stable ABI if it's there or not half the
time... that's the ultimate instability.

pm qos and cpufreq interaction [Was: pm qos infrastructure and interface]

[Dominik Brodowski]

Hi Mark,

On Thu, Oct 04, 2007 at 02:51:39PM -0700, Mark Gross wrote:
> Currently we have {cpu_dma_latency, network_latency, network_throughput}
> as the initial set of pm_qos parameters.

What about cpu_throughput{_min,_max}, as being something considered to be
proportional to the CPU frequency? This way, the cpufreq policy notifiers
might be able to utilize the pm_qos infrastructure; but maybe even also the
userspace interface (at least the min freq/max freq one)... Haven't thought
this through, but maybe you (or someone else) has.

Best,
	Dominik

PS: Each time I've tried to get back into business during the past
months, something got in between -- current issue is my terminally
broken notebook...

Re: pm qos and cpufreq interaction [Was: pm qos infrastructure and interface]

[Mark Gross]

On Tue, Oct 23, 2007 at 08:03:43PM +0200, Dominik Brodowski wrote:
> Hi Mark,
>

Its good to hear from you.  Will you be at the ELC conference in Linz
next week?

> On Thu, Oct 04, 2007 at 02:51:39PM -0700, Mark Gross wrote:
> > Currently we have {cpu_dma_latency, network_latency, network_throughput}
> > as the initial set of pm_qos parameters.
> 
> What about cpu_throughput{_min,_max}, as being something considered to be
> proportional to the CPU frequency? This way, the cpufreq policy notifiers
> might be able to utilize the pm_qos infrastructure; but maybe even also the
> userspace interface (at least the min freq/max freq one)... Haven't thought
> this through, but maybe you (or someone else) has.

I've only thought it though enough to choose to avoid cpufreq
interactions.  

Sadly core frequency is not proportional to throughput on X86
processors.  I don't know how one would reliably quantify cpu throughput
in this context, other than defining latencies.  

I could see something like this to prevent cpufreq throttling at bad
times, but how common of an issue is this any more?  

Are we wasting watts without such information?  Is CPUFREQ still making
some applications behave poorly?  Ondemand and cpufreq are fairly mature
now and I don't hear of such issues any more.  

--mgross

Re: pm qos and cpufreq interaction [Was: pm qos infrastructure and interface]

[Dominik Brodowski]

Hi Mark,

On Wed, Oct 24, 2007 at 02:21:50PM -0700, Mark Gross wrote:
> > On Thu, Oct 04, 2007 at 02:51:39PM -0700, Mark Gross wrote:
> > What about cpu_throughput{_min,_max}, as being something considered to be
> > proportional to the CPU frequency? This way, the cpufreq policy notifiers
> > might be able to utilize the pm_qos infrastructure; but maybe even also the
> > userspace interface (at least the min freq/max freq one)... Haven't thought
> > this through, but maybe you (or someone else) has.
> 
> I've only thought it though enough to choose to avoid cpufreq
> interactions.  
> 
> Sadly core frequency is not proportional to throughput on X86
> processors.  I don't know how one would reliably quantify cpu throughput
> in this context, other than defining latencies.  

Well it's not exactly throughput, but the CPU frequency surely has an
influence on it and also affects the quality of the service provided...

> I could see something like this to prevent cpufreq throttling at bad
> times, but how common of an issue is this any more?  

Hopefully none :) I was just wondering whether this generalization would
make sense in the big scheme of things (i.e. grand plan of unified power
management)...

> Its good to hear from you.  Will you be at the ELC conference in Linz
> next week?

Unfortunately not.

Best,
	Dominik

Re: pm qos and cpufreq interaction [Was: pm qos infrastructure and interface]

[Mark Gross]

On Thu, Oct 25, 2007 at 08:54:28PM +0200, Dominik Brodowski wrote:
> Hi Mark,
> 
> On Wed, Oct 24, 2007 at 02:21:50PM -0700, Mark Gross wrote:
> > > On Thu, Oct 04, 2007 at 02:51:39PM -0700, Mark Gross wrote:
> > > What about cpu_throughput{_min,_max}, as being something considered to be
> > > proportional to the CPU frequency? This way, the cpufreq policy notifiers
> > > might be able to utilize the pm_qos infrastructure; but maybe even also the
> > > userspace interface (at least the min freq/max freq one)... Haven't thought
> > > this through, but maybe you (or someone else) has.
> > 
> > I've only thought it though enough to choose to avoid cpufreq
> > interactions.  
> > 
> > Sadly core frequency is not proportional to throughput on X86
> > processors.  I don't know how one would reliably quantify cpu throughput
> > in this context, other than defining latencies.  
> 
> Well it's not exactly throughput, but the CPU frequency surely has an
> influence on it and also affects the quality of the service provided...

This is true.  I just worry going down this path would be a rat-hole.

FWIW I suppose one could use define bogo-mips as the throughput
parameter and use that as away for a CPUFREQ driver to use a way to
constrain the throttling.  This way if an application that knows it
needs higher throughputs and can't deal with the latencies of the
governor changing core voltage and frequencies, it could register itself
to PM_QOS.

In theory this could open a window to more aggressive governor policies
for saving power.   I can see how that could work well for specific
workloads but not so much for desktop / general purpose workloads..  

> 
> > I could see something like this to prevent cpufreq throttling at bad
> > times, but how common of an issue is this any more?  
> 
> Hopefully none :) I was just wondering whether this generalization would
> make sense in the big scheme of things (i.e. grand plan of unified power
> management)...
> 

Maybe you are right. 

Is there interest in anyone creating a new, or enhanced CPUFREQ governor
that takes advantage of a PM_QOS bogo-mips throughput parameter to limit
how low of a P-state to drop into?

If so I'd be happy to work with you to see what we can accomplish.


--mgross