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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
