Re: PM QoS dynamic resource manager

[mark gross <640e9920@gmail.com>]

On Tue, Jun 08, 2010 at 08:44:30AM -0600, Chidambaram, Praveen wrote:
> > Most of the ideas where around clock throttling of buses and memory.
> > Things like throttling the graphics BW to whatever memory it was using,
> > or clocking down the GPU when idle.  My thought was a pm_qos hint could
> > be handy, but I was assured that modern hardware auto-throttled and
> > didn't need this.  So I dropped it.  (At that time I also thought it
> > would apply to HD audio to allow better DAC throttling.  I also dropped
> > this one too for the same reasons.)
> 
> Yes, auto throttling by tying the Bus clock in relation to the CPU is 
> a fairly good idea, but cannot be the only solution. The drivers know 
> best their requirements and some drivers would need arbirated 
> bandwidth that no one else can encroach on.
> 
> > One problem was what type of units to use when talking about the qos of
> > the graphics was not obvious.  It needs to be something meaningful to  
> > be portable or provide a good abstraction.
> 
> With PM QoS you can specify one parameter. However, a single parameter 
> is quite insufficient. To specify bus bandwidth (say MBPS), we would 
> need 2 dimensional values. Buses are getting complex and the arbiters 
> that sit around them can make good decisions when they are fed the 
> right data. The clock speed is just one of them. To allocate a 
> bandwidth to a specific client, you would need to specify the amount 
> of data to be transferred and when transferred, the amount of data in 
> burst that need to be transferred would help in specifying the speed 
> for each transaction. The clock speed can be deduced by the 
> arbiter/driver from these two inputs.
> 
> > One problem was what type of units to use when talking about the qos of
> > the graphics was not obvious.  It needs to be something meaningful to
> > be portable or provide a good abstraction.
> 
> The units as we understand better are MBPS. They are something that 
> drivers can calculate before they make a request and request the 
> Bandwidth and the burst bandwidth to the arbiter.
> 
> What do you think about vector data inputs?
>
I think functional (as in functional programming) as pm_qos constraints
are an interesting science experiment and, mostly doable for simple
functions.  But on face level feel pretty complicated to me, and need a
good, easy to understand application or example to get the idea across.

I can imagine some multi-dimensional constraints, (mostly in the space of
limited power budgets and graceful degradation under limited load /
brown out situations.)  But that stuff is not QOS as much as an
optimization zero sum game problem.

So I think vector data inputs into a qos parameter needs clear
motivation.   yet interesting to think about.

--mgross