Re: [RFC] the generic thermal layer enhancement

[Zhang Rui <rui.zhang@intel.com>]

On 三, 2012-05-30 at 13:50 +0100, Matthew Garrett wrote:
> On Wed, May 30, 2012 at 04:49:02PM +0800, Zhang Rui wrote:
> 
> > G1. supporting multiple cooling states for active cooling devices.
> 
> Sounds fine.
> 
Great!

> > G2. introduce cooling states range for a certain trip point
> 
> Again, no problem here.
> 
Again, great!

> > 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.

Agreed.

> 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'm not sure if this could work on their platforms. So I'm just looking
for an easier way to handle this, i.e. make generic thermal layer
simple, and provide the flexibility for platform drivers to do their own
tricks.

> 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.
> 
Hmmm, I'd like to see if it is possible for them to make use of the
current passive cooling implementation.. if no...

how about this?

we can provide an API for the current algorithm in thermal_sys.c

thermal_passive_get_trend(int tc1, int tc2)
{
}
EXPORT_SYMBOL(...);

and in platform driver, they can choose to use this default algorithm if
they are able to.

.get_trend()
{
   return thermal_passive_get_trend(platform_tc1, platform_tc2);
}

> > 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?
> 
acceptable does not equal comfortable?
Say, I'd like to use the computer at 30C skin temperature.
I'm okay with the temperature at 50C, but it would be nice if it can be
lower, even if the system would be slower, but not too slow (T-state).
If the temperature is higher than 60, it is not usable for me, I'll wait
for a while, the system can do everything they want do cool the system
down (but hibernate/shutdown would be not a good idea at this time
because it is hot enough for some hardware damage).

thanks,
rui

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html