[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <alpine.LFD.2.00.1006171445010.4214@localhost.localdomain>
Date: Thu, 17 Jun 2010 15:00:15 -0400 (EDT)
From: Len Brown <lenb@...nel.org>
To: Igor.Stoppa@...ia.com
Cc: linux-pm@...ts.osdl.org, linux-kernel@...r.kernel.org,
linux-acpi@...r.kernel.org
Subject: RE: [linux-pm] RFC: /sys/power/policy_preference
On Thu, 17 Jun 2010, Igor.Stoppa@...ia.com wrote:
> i do understand that you are mostly targetting acpi based systems,
> but even there, based on static leaks, it might not be always true
> that lower frequencies are correlated to higher power savings
> (or maybe i have misunderstood your draft - i am not so fluent in acpi)
Right, my assertion is that ondemand deals only with P-states,
where, by defintion, the deeper the P-state the lower the voltage,
the higher the efficiency.
I assume that ondemand is not used to enable T-states
where the clock is throttled w/o lowering the voltage.
I put a note to try to make that clear under
max_powersave:
"ondemand: min P-state (do not invoke T-states)"
Of course it is also possible for a processor to do a poor job
implementing P-states and a great job optimizing idle states
such that race to idle were always a win. However, on such
a processor it would make more sense to simply disable P-states.
> > it is likely
> > that some users would want to use "powersave" when on
> > battery and perhaps shift to "performance" on A/C.
>
> if we consider also the thermal envelope and the fact that "performance"
> might steal power from a charging battery, even ton A/C it might not be
> possible to settle down in one state permanently.
>
> Or do you expect other mechanisms to intervene?
Typical laptop BIOS commonly implement a scheme where
they maximize performance on AC and bias towards saving energy
on DC.
That, of course, is just one example use-model.
Here Linux user-space can choose whatever policy
makes sense for them at run-time.
cheers,
-Len Brown, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists