[seems that posting via gmane is broken - resenting manually via mail
- sorry if you get duplicates]
mark gross <markgross@xxxxxxxxxxx> writes:
> On Fri, Jan 06, 2012 at 02:36:22AM +0200, Antti P Miettinen wrote:
[..]
>> diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
>> index 5ac91d8..7b8d08b 100644
>> --- a/include/linux/pm_qos.h
>> +++ b/include/linux/pm_qos.h
>> @@ -14,8 +14,11 @@ enum {
>> PM_QOS_CPU_DMA_LATENCY,
>> PM_QOS_NETWORK_LATENCY,
>> PM_QOS_NETWORK_THROUGHPUT,
>> + PM_QOS_CPU_FREQ_MIN,
>> + PM_QOS_CPU_FREQ_MAX,
> What is this about? How sould freq_max make any sense in the context of
> constraining power mangement throutling? this is wrong.
>
> You should only have a cpu throughput qos. I.e. FREQ_MIN.
> FWIW in my patch I named it : PM_QOS_CPU_THROUGHPUT but, its just a
> different name to your PM_QOS_CPU_FREQ_MIN name.
I anticipated getting this comment :-)
I originally added the max just for symmetry. But it could actually be
useful for e.g. requesting a minimum level of energy efficiency. If your
workload keeps CPU busy but does not need any specific throughput and
energy is more critical to you, by limiting the maximum frequency you
can request a level of energy efficiency (provided that the platform
DVFS works in a sensible way). Max frequency could be useful also for
thermal management.
Also, I think general "PM constraints" would be useful, not just
"minimum level of service" requests so why not extend PM QoS towards a
generic PM constraints framework?
--Antti
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
