Re-adding cpufreq and linux-pm MLs in Cc. Regards, Jean On Sat, Feb 25, 2012 at 6:44 PM, mark gross <markgross@xxxxxxxxxxx> wrote: > On Tue, Feb 21, 2012 at 10:00:18AM -0800, Kevin Hilman wrote: >> mark gross <markgross@xxxxxxxxxxx> writes: >> >> > On Mon, Feb 20, 2012 at 05:44:23PM +0200, Valentin, Eduardo wrote: >> >> Hello Antti, >> >> >> >> On Mon, Feb 20, 2012 at 12:00 PM, Antti P Miettinen >> >> <amiettinen@xxxxxxxxxx> wrote: >> >> > The following message is a courtesy copy of an article >> >> > that has been posted to gmane.linux.kernel.cpufreq,gmane.linux.power-management.general as well. >> >> > >> >> > Thanks for the comments. I'd like to comment on maximum CPU frequency, >> >> > sysfs files and per device contraints.. >> >> > >> >> > Maximum CPU frequency could be useful for thermal. However, it is not a >> >> > complete solution for thermal. Just like minimum CPU frequency is not a >> >> > complete solution for computing throughput (e.g. memory and accelerator >> >> > control are not directly addressed by a CPU frequency >> >> > constraint). Maximum CPU frequency can be also useful for energy >> >> > efficiency even though the constraint is not a complete solution here >> >> > either. I guess latency constraints do not completely solve end-to-end >> >> > latency requirements but the mechanism is useful so it is good to have >> >> > it. I'd argue minimum and maximum frequency are simular in this respect. >> >> > >> >> >> >> I believe we are aligned that this is not complete solution, but the >> >> constraints does help on both cases. >> >> >> >> > There are sysfs files for constraining CPU frequency. However, there is >> >> > no arbitration for several applications trying to place constraints. PM >> >> > QoS provides a way to consolidate requests from several applications and >> >> > cleanup upon application crash. I think the existing sysfs files are not >> >> > an appropriate inferface for user space applications. >> >> >> >> Agreed, the current CPU frequency interfaces were not design to >> >> achieve lists of constraints at all, but they had very simplistic >> >> design which you would consider the last constraint applied. >> >> >> >> But the point Mark was trying to bring was that PM QoS was not really >> >> meant for max- like constraints. As he said, that is not for QoS but >> >> for constraints. We may be abusing a bit the FW by addressing the >> >> problem with it. That would look like more as a pm-constraint FW. >> >> >> >> It just happens to be so that the PM QoS has already the needed infrastructure. >> >> >> > >> > Aside from the naming and design intents of pm_qos (qos vrs perforce >> > constraints) which I acknowledge is arguably not a good reason on its >> > own to block this, the other issue I have is that thermal constraints >> > are much more dynamic than pm-qos constraints and I don't think the >> > existing framework is up to it. >> > >> > almost all applications of pm-qos are static. >> >> Not true. >> >> With the new per-device PM QoS, we are adding/removing constraints >> dynamically depending on usage. Drivers/subsystems add/remove >> constraints depending on what is happening and their needs. This can >> happen dynamically and very often. > > I have to admit I no experience and limited insight into the per-device > pm-qos or how its getting used. However; I think there is a difference > between dynamic use cases and ambient environmental effects on the > system. > >> Also, as you know based on changes submitted to PM QoS infrastructure >> after it's initial addition, lots of work was done so that it can be >> used in the fast path, so many people care about the ability to change >> constraints dynamically. > > true. > >> > Some device has a lower bound of performance needed by some other >> > platform component and uses pm-qos to request tat the lower bound not >> > be violated. >> >> And with per-device constraints (I prefer the term constraints too), >> this can be very dynamic, and very targetted. e.g. the constraint might >> apply to a single power domain/island and can can be added/removed >> dynamically and often. >> >> > Performance constraints depend on dynamic values (temperature, peak >> > current, perhaps someday even noise) that are effected by ambient >> > conditions. >> >> And current QoS settings also depend on dynamic values: instantaneous >> throughput, frequency dependencies between IP blocks, etc. etc. >> Depending on which devices/subsystems are in use by a given usecase, >> these are all dynamic conditions. > > They are static per use case. Just because the use case can change > dynamically does not make it dynamic in the same sense as thermal or > battery power envelopes. > > Further the effects of truly dynamic conditions is significant to the > user. > >> > I think adding perf-constraints to the pm-qos without taking the time to >> > think through these things to be a quick and dirty hack. >> >> I don't see it that way, and to me it's a very logical extention. >> > > I see it as a convenient extension that is very close to being a quick > hack. That only solves a small part of a more general problem. > >> Current QoS settings could be thought of as performance constraints >> too. It's just that they determine minimum performance. Adding >> constraints for maxium performance is not a big stretch in my mind. > > Its not a big stretch to me either. I just think its a bit of a hack > and there is a bigger more interesting issue getting overlooked. > > Lastly why not simply make cpufreq thermal aware and talk directly to > it if you even need too? > > --mark > >> Kevin >> >> > I don't know >> > if we should be quick and dirty with main line changes like this. maybe >> > pm-qos only needs some dynamic constrain aggregation (for ambiant >> > conditions) and a few new constraint classes. Maybe there needs to be >> > more done. >> > >> > maybe I'm over thinking it and we should simply add the perf-constraint >> > class. >> >> >> >> >> >> >> > >> >> > Currently CPU sleep states are blocked globally for latency >> >> > contraints. Finer granularity control would be possible with per CPU >> >> > contraints. However - are there clients that know or want to contrain a >> >> > specific CPU? Same question is applicable also to CPU frequency. Even >> >> > though per CPU control is more flexible, what are the clients that want >> >> > to constrain a specific CPU? >> >> >> >> If I got your point right, I agree with you, we definitely need a way >> >> to expose who is setting the constraint. >> >> >> >> > >> >> > Another complication for the per device constraints is the user space >> >> > interface. Dynamic minors run out pretty fast if we have per CPU >> >> > parameters and the system has huge number of CPUs. Does anyone have any >> >> > opinions about the user space interface for device PM QoS? >> >> > >> >> > --Antti >> >> >> >> >> >> All best, >> >> >> >> -- >> >> >> >> Eduardo Valentin _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
