Thread (22 messages) 22 messages, 5 authors, 2012-05-31

Re: [RFC] the generic thermal layer enhancement

From: Matthew Garrett <mjg59@srcf.ucam.org>
Date: 2012-05-30 12:50:47
Also in: linux-acpi

On Wed, May 30, 2012 at 04:49:02PM +0800, Zhang Rui wrote:
G1. supporting multiple cooling states for active cooling devices.
Sounds fine.
G2. introduce cooling states range for a certain trip point
Again, no problem here.
G3. kernel thermal passive cooling algorithm
    Currently, tc1 and tc2 are hard requirements for kernel passive
    cooling. But non-ACPI platforms do not have this information
    (please correct me if I'm wrong).
    Say, for the patches here
    http://marc.info/?l=linux-acpi&m=133681581305341&w=2
    They just want to slow down the processor when current temperature
    is higher than the trip point and speed up the processor when the
    temperature is lower than the trip point.
Just slowing the CPU down above a certain temperature is a pretty awful 
approach to passive cooling. You want to maximise performance while 
staying within your thermal envelope, so you need a more advanced 
approach. The existing algorithm provides a generic mechanism for 
balancing performance and thermal output, with the only requirement 
being that the platform provide constants that represent the heating and 
cooling properties of the system.

I don't fundamentally object to adding support for platform-specific 
passive formulae, but I'd like an explanation for how they're better 
than the existing one.
G4. Multiple passive trip points
It would be good to have an explanation of the use case here. If it's 
acceptable for the device to be at the lower passive trip point, why are 
we slowing it down at all?

-- 
Matthew Garrett | mjg59@srcf.ucam.org
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help