> -----Original Message----- > From: linux-pm-bounces@xxxxxxxxxxxxxxxxxxxxxxxxxx [mailto:linux-pm- > bounces@xxxxxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Antti P Miettinen > Sent: Tuesday, January 17, 2012 11:45 AM > To: linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx > Cc: cpufreq@xxxxxxxxxxxxxxx > Subject: Re: [PATCH v2 0/8] RFC: CPU frequency min/max as PM QoS > params > > "Rafael J. Wysocki" <rjw@xxxxxxx> writes: > > If that hasn't been clear enough so far, I'm still not convinced that > > using PM QoS for that is a good idea. > > > > First off, frequency as a unit of throughput is questionable to say > > the least, because it isn't portable from one system to another. > > Moreover, even on a given system it isn't particularly clear what the > > exact correspondence between frequency and throughput actually is. > > > > Second, it's not particularly clear what the meaning of the "min" > > frequency is supposed to be in terms of throughput. > > > > Moreover, you make cpufreq export user_policy.min and user_policy.max > > regardless of the new PM QoS parameters, so it looks like you could > > use those new attributes to set the min/max as well. > > > > Thanks, > > Rafael > > Thanks - yes - I've understood you are not convinced :-) > > Is there any reason why the mapping from application oriented performance > requirement metric to hardware oriented performance setting metric would > need to be inside kernel? As I've said (and Mark Gross seems to agree) the > performance requirements are likely to be system specific and probably obtained > via trial and error or some kind of adaptive iteration. Wouldn't it be better to > leave this complexity outside PM QoS core or even outside kernel if possible? > > The change to cpufreq core just adds two read-only files to be able to inspect > user_policy.min/max in addition to the currently enforced > policy->min/max. Yes - there has been the possibility of using the sysfs > min for setting a frequency floor but this is problematic when there are multiple > clients. You'd need some kind of arbitration and book keeping to set/restore the > minimum. And PM QoS provides exactly this mechanism. > > I think the kernel needs to be extended to handle more PM constraints and PM > QoS is the closest thing I know for this kind of functionality. However, I'm open to > suggestions about alternative approaches. I think we need e.g. more than just > min/max "reduction operators". Ideas, anyone? How about a notion of platform agnostic freq metric that can then me normalized to The platform available freq's like for example a value 100 that denotes top freq, that Way PM QoS can then ajust the application requested number to platform available Freq. Just like the On-Demand power_savebias option that uses 0 for the highest freq -Illyas _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
