Hello, On Fri, Feb 17, 2012 at 5:04 AM, mark gross <markgross@xxxxxxxxxxx> wrote: > On Wed, Feb 15, 2012 at 05:06:40PM -0800, Kevin Hilman wrote: >> Hello, >> >> Antti P Miettinen <amiettinen@xxxxxxxxxx> writes: >> >> > This is a continuation to "RFC: CPU frequency min as PM QoS param" >> > patchset. This patchset adds CPU frequency maximum as a PM QoS >> > parameter and modifies CPU frequncy core to enforce the limit. CPU >> > frequency ceiling can be used to improve the energy efficiency of >> > workloads that would cause the cpufreq governors to enforce an >> > unnecessarily high operating point. In other words, CPU frequency >> > maximum can act as an energy efficiency level request. >> > >> > Tested on Dell E6420 with the ACPI cpufreq driver against Ubuntu >> > 3.2. Patches are against linux-next, compile tested. >> >> I know there were some earlier discussions about the usefulness of a max >> frequency QoS parameter, so I wanted to throw in a reason to include max >> as well as min frequency parameters. >> >> IMO, having a max frequency QoS parameter would be very useful from a >> thermal perspective. >> >> There are some ongoing projects in the PM working group at Linaro that >> are exploring plugins to the thermal framework that implment a "cooling >> device" by capping CPU frequency. Having a QoS parameter do do this >> would be the logical interface. I saw the work started by Amit (Cced), but I believe we may need to expand it. >> >> I also agree with some earlier requests that these should probably be >> per-CPU instead of global. That would make it simple to cap frequency >> of one cluster while leaving another alone. I believe we need to consider a broader set of cases, not only cpu. >> > Hi, > > My problem is that overloading pm_qos with a performance limits is a > hack that will likely have problems coexisting with the core notion of > throttling limiting that is pm_qos as thermal limiting enabling expands > its scope. > > Sure limiting performance governors seem to need the same notifications > and infrastructure as pm_qos but I worry that as its really doing the > opposite to qos I really don't see the logic of having it in pmqos. > > Lets consider thermal throttling a bit maybe I can convince you to that > maybe we need some new mechanism for energy and thermal limiting. (BTW > I agree something is needed for this). > > For thermals the culprit's are: > cpu -- cpufreq governor currently not-thermal aware > Display -- brightness not thermal aware > GFX -- graphics driver not thermal aware > battery charging -- somewhat thermal aware but needs more than just bat > temp to count. > Flash -- led flash light not thermal aware. This is probably what we want to consider, at least to start with. As Mark mentions above, the cpu domain is just part of the equation. The work started by Amit is going towards the right direction, but I believe we need to review the thermal problem for those systems that don't have ACPI. The generic part of current thermal framework (drivers/thermal/) is still somewhat bound to ACPI. > > Other devices may have other heat sources of course. Indeed. > > Wouldn't it be better to have thermal awareness as part of the driver > model and then have a pm_qos like thing to do out of band signaling of > devices and user mode when a temperature is hit? > Having things exposed to drivers is maybe one we to go, but we need to be careful and not leave the decision making to drivers, IMO. Might be worth considering thermal governors as well, instead of having the decision making spread all over driver code. The point I am trying to make here is that sometimes you may want to consider correlation between these thermal domains. > Putting it a qos class for limiting the high end of the performance that > a governor really doesn't go far enough IMO. It looks like a hack just > for cpufreq that already has sysfs interfaces for limiting the top > frequency. > > ok, maybe my argument is not so strong. but as long as its named pm QOS > and not pm-constraints I don't like the idea of having the max > parameter in the pm_qos code. I also agree that this type of problem goes more like a set of constraint instead of trying to keep QoS. > > It feature creeps the infrastructure and violates the spirit of what > pm_qos was to solve. i.e. constrain the lower power states not upper > states. > > But, for thermal / energy management I think we need more notification > of thermal or energy events than what is needed for the pm_qos problem. > > For pm_qos its mostly a static problem that is tuned in the lab. Know > the workload needs and block too much throttling. For thermal / energy > management you isn't any tuning you can do. You don't apply the > constraint until it gets too hot. You don't know if or when you'll get > too hot. > > Note: its more than just temperature that we need to worry about. Peak > current is also a related issue (that is much more transient) > > Shouldn't we do something more forward looking than hack pm_qos with > max-freq so that cpufreq can check a redundant parameter to what it > already has exported through sysfs? Agreed here, we need something to represent the problem in better way. But, I believe what is currently at the sysfs for cpufreq is a constraint set by user, and for thermal aspect, sometimes you can not confuse what the user has set to what the system really needs. The system may not want to wait for user to say you have to reduce performance in order to try contain thermal, specially if the situation is going critical, or as you mentioned, to consider peak current management as well. So, I believe we need to consider both as different constraints. Besides having these constraints coming from different places and not having a good way to show what is going on on the system (and also good ways to debug it) is something that may need to be thought as well. > > > --mark > > _______________________________________________ > linux-pm mailing list > linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linuxfoundation.org/mailman/listinfo/linux-pm All best, -- Eduardo Valentin _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
