From mboxrd@z Thu Jan 1 00:00:00 1970 From: mark gross <640e9920@gmail.com> Subject: Re: PM QoS dynamic resource manager Date: Tue, 8 Jun 2010 19:55:51 -0700 Message-ID: <20100609025551.GC26668@gvim.org> References: <20100525145223.GA4974@gvim.org> <20100608033333.GA23066@gvim.org> Reply-To: markgross@thegnar.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-pm-bounces@lists.linux-foundation.org Errors-To: linux-pm-bounces@lists.linux-foundation.org To: "Chidambaram, Praveen" Cc: kheitke@codeaurora.org, linux-pm@lists.linux-foundation.org, mark gross <640e9920@gmail.com>, markgross@thegnar.org List-Id: linux-pm@vger.kernel.org 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