Re: [linux-pm] [PATCH 0/2] RFC: CPU frequency max as PM QoS param

["Pihet-XID, Jean" <j-pihet@ti.com>]

Re-adding cpufreq and linux-pm MLs in Cc.

Regards,
Jean

On Sat, Feb 25, 2012 at 6:44 PM, mark gross <markgross@thegnar.org> wrote:
> On Tue, Feb 21, 2012 at 10:00:18AM -0800, Kevin Hilman wrote:
>> mark gross <markgross@thegnar.org> 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@nvidia.com> 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