Re: [PATCH] pm_qos: Add system bus performance parameter

[Kevin Hilman <khilman@deeprootsystems.com>]

mark gross <markgross@thegnar.org> writes:

> On Fri, Aug 27, 2010 at 07:55:37PM -0700, Saravana Kannan wrote:
>> mark gross wrote:
>> >On Fri, Aug 27, 2010 at 01:10:55AM -0700, skannan@codeaurora.org wrote:
>> >>Ignoring other details for now, the biggest problem with throughput/KBps
>> >>units is that PM QoS can't handle it well in its current state. For KBps
>> >>the requests should be added together before it's "enforced". Just picking
>> >>the maximum won't work optimally.
>> >
>> >well then current pm_qos code for network throughput takes the max.
>> 
>> I don't know how the network throughput is enforced, but if the unit
>> is KBps and it's just doing a Max, then I think it's broken. If two
>> clients request 50 KBps and your network can go till 200 KBps, you
>> would still be requesting 50 KBps when you could have requested 100
>> KBps.
>> 
>> Any specific reason PM QoS doesn't support a "summation" "comparitor"?
>
> PM_QoS could do a summation, but keep in mind it pm_qos not qos.  pm_qos
> is a best effort thing to constrain power management throttling, not
> provide a true quality of service or deadline scheduling support.

For me (and I think Saravana too), this is still all about power, but
it's closely tied to QoS.  

For things like busses, which are inherently shared, PM is tightly
coupled with "true" QoS, so I'm not sure I fully follow the distinction
being made between PM QoS and QoS.  Seems like the tradeoff is always
between power and performance.

> If you stick to the full up quality of service mentality you quickly get
> into discussions just like those around memory over commit.  Its really
> hard to know when best effort or hard QoS is appropriate.
>
> If you are trying to use pm_qos as a true qos interface then, its
> definitely not up to the task.
>
> example:  you have one 100Mb NIC in your box.  With PM QoS you could
> have 4 user mode applications requesting 100Mbs PM_Q0S.  In this case
> the right thing to do is to constrain the NIC PM to keep it full on and
> the PHY going as fast as it can.  But you'll never get 400Mbs out of the
> thing.
>
> So far only max and min really have made sense for pm_qos but, if a case
> pops up where summation makes more sense for aggregating the pm_qos
> requests then I'm open to it.

Using your example above, what if the 4 apps all request 10Mb/s?

What is best effort?  Leave the NIC in 10Mb/s mode, or bump up the power
state to 100Mb/s mode?

This decision is both QoS and PM related.  Without summation, the 'max'
request is still 10Mb/s so you would keep the lower power state.  But
you also know that none of the clients will get their requested rate.

There's some gray area here since there is a choice.  Was the point
of the request to keep the NIC at the *power-state* needed for 10Mb/s (a
PM request) or was the request saying the app wanted at least 10Mb/s (a
QoS request.)  

My understanding is that PM QoS is intended to limit power-state
throttling.  IOW, in the absence of PM QoS requests, the PM core code is
free to throttle the power of the devices/subsystems/busses etc.  If
requests are present, it is no longer free to throttle blindly.

The question here seems to be whether or not the PM core code should
also be free to increase the power state to meet a combination of PM QoS
requests.  To me this is still PM related.  Just like in race-to-idle
for the CPU, it might be better for overall power to go to the highter
state for a burst and then be able to fully throttle again.

Kevin