On Fri, Dec 18, 2009 at 06:51:38PM -0700, Ai Li wrote: > Subject: platform specific pm_qos parameters > From: Ai Li <aili@xxxxxxxxxxxxxx> > To: mgross@xxxxxxxxxxxxxxx, linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx > Date: Fri, 18 Dec 2009 18:51:38 -0700 > > Hi, > > We are interested in using pm_qos_params to reduce power consumption > on our embedded devices while maintaining satisfactory performance. > One example of the QoS parameters is bus bandwidth. We want to slow > down the buses dynamically to a lower level and yet provide enough > bandwidth to the system. > > On our devices, different product families can have different type of > buses and different number of buses. I remember that folks were > asking about platform specific pm_qos parameters some time ago. It > seems a natural fit for us to create a different set of bandwidth QoS > for each platform. My initial reaction is why can't we come up with a good abstraction that would work for the product families? I think its ok for a pm-qos option to exist but not be used on every architecture. > > I haven't seen much discussion recently on platform specific > pm_qos_params. Are people still open to the idea? I also would like > to help working on it. I worry that this is the road to hell. If the platform specific pm-qos parameter is accessed by any platform independent driver code then its a big failure and leads to code that will give me a rash to look at. So one requirement for platform specific pm-qos parameters I have is that such parameters shall only be accessible from platform specific code and not from any platform independent stuff. (I don't think this is possible in C, so I'll need more convincing to not block this idea.) I welcome help coming up with good pm-qos abstractions for the multiple bus bandwidth problem above. Having a nice discussion about the problem space would be good start, then we can propose some possible abstractions and prototype some implementations. It also is important to provide some application specific motivation as to why the buses you are calling out can not self throttle without causing issues. I once had a graphics bus example in mind but I've been told that graphics drivers have the data needed to do effective throttling and they already do so. Therefore I shouldn't bother with such parameters. I don't know if I believe that but I don't feel like arguing with graphics experts too much on the matter without a specific application where the need for such a parameter could be used. i.e. I need a graphics driver author or graphics Si vendor to step up and tell us they could do a lot better with power if a pm-qos parameter for graphics bus bandwidth existed. So do you see my issue? I hope I'm not scaring you off. I want to do more with pm-qos but it takes collaboration to make it happen. Today, I feel adding platform specific PM-QOS would put off solving the problems by enabling device specific parameters that would be forever out of tree and delay the collaboration needed to move forward. --mgross ps, sorry for using my wonky email address, I'm away form the linux.intel.com server until Jan. > > ~Ai > > > _______________________________________________ > linux-pm mailing list > linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linux-foundation.org/mailman/listinfo/linux-pm
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
