On Mon, Jan 16, 2012 at 10:38:57PM +0100, Rafael J. Wysocki wrote: > Hi, > > On Monday, January 16, 2012, Antti P Miettinen wrote: > > [did not reach linux-pm as I sent to wrong address, sorry for > > duplicates] > > > > The inspiration for this patch series is the N9 CPU frequency boost > > upon input events: > > > > http://www.spinics.net/lists/cpufreq/msg00667.html > > > > and the related changes in git://codeaurora.org/kernel/msm.git tree. > > Those patches modify the ondemand cpufreq governor. This patch series > > adds minimum and maximum CPU frequency as PM QoS parameters and > > modifies the cpufreq core to enforce the PM QoS limits. > > 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. You are right. The notion of throughput of a CPU is really hard to quantify. Perhaps not using the term "throughput" would help? The base issue I see, the Intel platform, is needing is that sometimes we need to block the lowest P-states that the ondemand governor goes for because those P-states result in media / graphics workloads dropping frames. However; GPU intensive workloads do not stress the CPU so the ondemand governor goes for the low p-state. I could use some way of constraining the PM-throttling of the cpu-freq that can be hit from kernel or user mode. So the graphics driver can dynamically adjust the constraint request on the cpufreq subsystem. It is problematic that any driver requesting a given frequency request is not portable across ISA's or even processor families in the same ISA. But, maybe such a driver should use a module parameter to work around this lack of portability? > Second, it's not particularly clear what the meaning of the "min" frequency > is supposed to be in terms of throughput. It should mean "please cpufreq do not put the cpu into a state where its clock runs slower than min". I don't think we should talk about it as throughput because thats not what the cpufreq controls. > > 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. I'm not a big fan of the cpufreq seamanly redundant export either. Doesn't the equivalent data get exported under /sys/devices/system/cpu/cpu?/cpufreq/ ? my 2 cents. --mark _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
