Thermal notifications without setting thermal governor to userspace?

Thermal notifications without setting thermal governor to userspace?

[Chris Down]

Hey thermal folks,

I'm hoping that you'll be able to provide some guidance on what options are 
available for getting thermal notifications without changing the policy to 
userspace control.

To be clear, my intent is to have a userspace daemon which can set multiple 
temperature trips at runtime on which it can receive a notification (preferably 
by a simple mechanism like uevents), and to be able to distinguish which 
threshold was tripped. For example, to be able to set trips at 50C, 70C, and 
90C, getting events both when the temperature exceeds that and when it dips 
back under the specified threshold.

Right now I am polling /sys/class/thermal/thermal_zone*/temp but this can be 
expensive, especially for the ACPI thermal zone.

As it is, I see four options:

1. Set thermal_zone to use user_space governor and use uevents

As I understand it, this means that the default critical temperature will no 
longer be respected and user space is now responsible for taking action to 
control thermal events.

If that's correct, then it seems dangerous to set it to user_space for 
userspace applications which only want to monitor their own trip temperatures, 
but not take direct action.

2. Use hwmon thermal events

I see that commit 1597b374af22 ("hwmon: Add notification support") adds 
notification support to hwmon, but as far as I can tell this is based on 
statically defined trip temperatures from ACPI or similar inputs. I see you can 
change it with the thermal.crt boot option, but that's too early for a normal 
userspace daemon to do anything (and it doesn't allow any dynamic 
reconfiguration).

3. Use thermal over netlink

I see that commit 1ce50e7d408e ("thermal: core: genetlink support for 
events/cmd/sampling") which was merged a couple of years ago adds support for 
thermal netlink events.

I also see articles suggesting that support for this new netlink interface will 
be or was added to libnl, but I can't seem to find anything about it in the 
libnl sources.

Is this mature enough to use? If so, does one have to hack up their own 
userspace netlink library for now, or what's the plan there?

In general I would prefer something simpler that fits into the existing strong 
tooling around uevents/etc though, this looks useful, but it does a lot more 
than I need and requires adding another userspace dependency on libnl.

4. Poll /sys/class/thermal/thermal_zone*/temp or hwmon

This is what I'm currently doing. It's slow, and often unnecessarily costly on 
weaker systems.

Are there other options I'm not considering here that might help me out here?

Thanks,

Chris

Re: Thermal notifications without setting thermal governor to userspace?

[Daniel Lezcano]

Hi Chris,

I'll answer to your email but meanwhile this can have some interest for you:

 
https://lore.kernel.org/all/20220330100444.3846661-1-daniel.lezcano@linaro.org/

Regards

  -- Daniel

On 30/03/2022 17:45, Chris Down wrote:
> Hey thermal folks,
> 
> I'm hoping that you'll be able to provide some guidance on what options 
> are available for getting thermal notifications without changing the 
> policy to userspace control.
> 
> To be clear, my intent is to have a userspace daemon which can set 
> multiple temperature trips at runtime on which it can receive a 
> notification (preferably by a simple mechanism like uevents), and to be 
> able to distinguish which threshold was tripped. For example, to be able 
> to set trips at 50C, 70C, and 90C, getting events both when the 
> temperature exceeds that and when it dips back under the specified 
> threshold.
> 
> Right now I am polling /sys/class/thermal/thermal_zone*/temp but this 
> can be expensive, especially for the ACPI thermal zone.
> 
> As it is, I see four options:
> 
> 1. Set thermal_zone to use user_space governor and use uevents
> 
> As I understand it, this means that the default critical temperature 
> will no longer be respected and user space is now responsible for taking 
> action to control thermal events.
> 
> If that's correct, then it seems dangerous to set it to user_space for 
> userspace applications which only want to monitor their own trip 
> temperatures, but not take direct action.
> 
> 2. Use hwmon thermal events
> 
> I see that commit 1597b374af22 ("hwmon: Add notification support") adds 
> notification support to hwmon, but as far as I can tell this is based on 
> statically defined trip temperatures from ACPI or similar inputs. I see 
> you can change it with the thermal.crt boot option, but that's too early 
> for a normal userspace daemon to do anything (and it doesn't allow any 
> dynamic reconfiguration).
> 
> 3. Use thermal over netlink
> 
> I see that commit 1ce50e7d408e ("thermal: core: genetlink support for 
> events/cmd/sampling") which was merged a couple of years ago adds 
> support for thermal netlink events.
> 
> I also see articles suggesting that support for this new netlink 
> interface will be or was added to libnl, but I can't seem to find 
> anything about it in the libnl sources.
> 
> Is this mature enough to use? If so, does one have to hack up their own 
> userspace netlink library for now, or what's the plan there?
> 
> In general I would prefer something simpler that fits into the existing 
> strong tooling around uevents/etc though, this looks useful, but it does 
> a lot more than I need and requires adding another userspace dependency 
> on libnl.
> 
> 4. Poll /sys/class/thermal/thermal_zone*/temp or hwmon
> 
> This is what I'm currently doing. It's slow, and often unnecessarily 
> costly on weaker systems.
> 
> Are there other options I'm not considering here that might help me out 
> here?
> 
> Thanks,
> 
> Chris


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: Thermal notifications without setting thermal governor to userspace?

[Chris Down]

Hi Daniel,

Daniel Lezcano writes:
>I'll answer to your email but meanwhile this can have some interest for you:
>
>
>https://lore.kernel.org/all/20220330100444.3846661-1-daniel.lezcano@linaro.org/

Thanks! Glad to see that it's making progress.

I'll wait for your reply on the e-mail overall then :-)

Thanks,

Chris

Re: Thermal notifications without setting thermal governor to userspace?

[Daniel Lezcano]

Hi Chris,

On 30/03/2022 17:45, Chris Down wrote:
> Hey thermal folks,
> 
> I'm hoping that you'll be able to provide some guidance on what options 
> are available for getting thermal notifications without changing the 
> policy to userspace control.

That is now possible with the netlink notifications mechanism.

https://www.linaro.org/blog/thermal-notifications-with-netlink/

> To be clear, my intent is to have a userspace daemon which can set 
> multiple temperature trips at runtime on which it can receive a 
> notification (preferably by a simple mechanism like uevents), and to be 
> able to distinguish which threshold was tripped. For example, to be able 
> to set trips at 50C, 70C, and 90C, getting events both when the 
> temperature exceeds that and when it dips back under the specified 
> threshold.

For that it would require to setup a trip point from the firmware 
dedicated to userspace management along with the writable trip point 
kernel config option.

On embedded systems, the trip point can be added easily in the device tree.

You would end up with:

  - one passive trip point : writable and used by userspace

  - one passive trip point to protect the system tied with a cooling 
device and handled by the kernel

  - one hot trip point to notify the userspace critical is about to be reach

  - one critical trip point to reboot the system

 From the userspace, you change the trip temp to 50°C, 70°C and 90°C 
when crossing the way up or the way down.

The sensor should implement the set_trip in order to program the 
register to fire the interrupt at the specified temperature. Otherwise, 
monitoring will be needed.

On ACPI, except hacking the table and reload from the kernel I don't see 
how to do that.


> Right now I am polling /sys/class/thermal/thermal_zone*/temp but this 
> can be expensive, especially for the ACPI thermal zone.
> 
> As it is, I see four options:
> 
> 1. Set thermal_zone to use user_space governor and use uevents
> 
> As I understand it, this means that the default critical temperature 
> will no longer be respected and user space is now responsible for taking 
> action to control thermal events.

The userspace governor is marked deprecated and will be removed soon. 
The decision was because this governor was only used for the sake of 
having the notification but at the cost of losing the in-kernel control 
of the thermal zone.

The netlink notification solving that, the userspace governor is no 
longer needed.

> If that's correct, then it seems dangerous to set it to user_space for 
> userspace applications which only want to monitor their own trip 
> temperatures, but not take direct action.

Right

> 2. Use hwmon thermal events
> 
> I see that commit 1597b374af22 ("hwmon: Add notification support") adds 
> notification support to hwmon, but as far as I can tell this is based on 
> statically defined trip temperatures from ACPI or similar inputs. I see 
> you can change it with the thermal.crt boot option, but that's too early 
> for a normal userspace daemon to do anything (and it doesn't allow any 
> dynamic reconfiguration).
> 
> 3. Use thermal over netlink
> 
> I see that commit 1ce50e7d408e ("thermal: core: genetlink support for 
> events/cmd/sampling") which was merged a couple of years ago adds 
> support for thermal netlink events.
> 
> I also see articles suggesting that support for this new netlink 
> interface will be or was added to libnl, but I can't seem to find 
> anything about it in the libnl sources.
> 
> Is this mature enough to use? If so, does one have to hack up their own 
> userspace netlink library for now, or what's the plan there?


For the record, everything is here:

https://lore.kernel.org/all/20220330100444.3846661-1-daniel.lezcano@linaro.org/


> In general I would prefer something simpler that fits into the existing 
> strong tooling around uevents/etc though, this looks useful, but it does 
> a lot more than I need and requires adding another userspace dependency 
> on libnl.


Yeah, that is the drawback.


> 4. Poll /sys/class/thermal/thermal_zone*/temp or hwmon
> 
> This is what I'm currently doing. It's slow, and often unnecessarily 
> costly on weaker systems.

If the sensor backend drivers has the set_trip ops working and setting 
the interrupt for the next threshold, that should be solved with the 
writable trip point.

Otherwise, the netlink sampling channel can be used with the in-kernel 
monitoring. The cost of a back and forth netlink message is 14us on a 
Cortex-A75@2.8GHz (the half if just getting a notification or sampling)

> Are there other options I'm not considering here that might help me out 
> here?

Yes, I assume the daemon gets notification but has to do an action. 
Usually, it acts on the cooling device and that is bad.

There is a power capping framework called DTPM which aims to provide a 
way to set a power limitation on the device. As it is very new, it is 
only supporting ARM with an energy model for CPU and any devfreq device 
(eg. GPU and memory).

More details here:

https://resources.linaro.org/en/resource/oyFSkedFn1RPeSLKhcQ1T3


Hope that helped

   -- Daniel


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: Thermal notifications without setting thermal governor to userspace?

[Chris Down]

Hey Daniel,

Thanks a lot for getting back!

Daniel Lezcano writes:
>For that it would require to setup a trip point from the firmware 
>dedicated to userspace management along with the writable trip point 
>kernel config option.
>
>On embedded systems, the trip point can be added easily in the device tree.
>
>You would end up with:
>
> - one passive trip point : writable and used by userspace
>
> - one passive trip point to protect the system tied with a cooling 
>device and handled by the kernel
>
> - one hot trip point to notify the userspace critical is about to be reach
>
> - one critical trip point to reboot the system
>
>From the userspace, you change the trip temp to 50°C, 70°C and 90°C 
>when crossing the way up or the way down.
>
>The sensor should implement the set_trip in order to program the 
>register to fire the interrupt at the specified temperature. 
>Otherwise, monitoring will be needed.
>
>On ACPI, except hacking the table and reload from the kernel I don't 
>see how to do that.

In my case I'm dealing with "normal" desktop machines and a distribution 
kernel, so it isn't possible to have fine grained control over the kernel 
configuration or device tree (especially since ideally this would be 
usable as an unprivileged user).

Is it still possible to use this in such a scenario?

Re: Thermal notifications without setting thermal governor to userspace?

[Daniel Lezcano]

Hi Chris,

On 04/04/2022 17:17, Chris Down wrote:
> Hey Daniel,
> 
> Thanks a lot for getting back!
> 
> Daniel Lezcano writes:
>> For that it would require to setup a trip point from the firmware 
>> dedicated to userspace management along with the writable trip point 
>> kernel config option.
>>
>> On embedded systems, the trip point can be added easily in the device 
>> tree.
>>
>> You would end up with:
>>
>> - one passive trip point : writable and used by userspace
>>
>> - one passive trip point to protect the system tied with a cooling 
>> device and handled by the kernel
>>
>> - one hot trip point to notify the userspace critical is about to be 
>> reach
>>
>> - one critical trip point to reboot the system
>>
>> From the userspace, you change the trip temp to 50°C, 70°C and 90°C 
>> when crossing the way up or the way down.
>>
>> The sensor should implement the set_trip in order to program the 
>> register to fire the interrupt at the specified temperature. 
>> Otherwise, monitoring will be needed.
>>
>> On ACPI, except hacking the table and reload from the kernel I don't 
>> see how to do that.
> 
> In my case I'm dealing with "normal" desktop machines and a distribution 
> kernel, so it isn't possible to have fine grained control over the 
> kernel configuration or device tree (especially since ideally this would 
> be usable as an unprivileged user).
> 
> Is it still possible to use this in such a scenario?

Well on regular desktop, the thermal is managed under the hood by the 
firmware/hardware, few sensors are exported AFAICT. I don't think a 
thermal daemon would have a benefit on these platforms.

Anyway. The temperature is not moving so quickly with all the heat sinks 
on the desktop components usually, so monitoring the temperature with a 
pid loop and increase the sampling when getting closer to a temperature 
should be fine.

Just to clarify, userspace should not manage the thermal zones but the 
overall temperature by acting on the different heating sources' 
performance indexes.

Regarding the unprivileged access, it is not possible to act on the 
performance state of the different components for non-root users. It 
would require to setup the file capabilities for your program which is 
probably what you want.



-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: Thermal notifications without setting thermal governor to userspace?

[Chris Down]

Daniel Lezcano writes:
>Well on regular desktop, the thermal is managed under the hood by the 
>firmware/hardware, few sensors are exported AFAICT. I don't think a 
>thermal daemon would have a benefit on these platforms.

Maybe we have different expectations? On my laptop, a Thinkpad T14s, things 
seem not too bad:

     % printf '%s\n' /sys/class/hwmon/hwmon*/temp*_input
     /sys/class/hwmon/hwmon1/temp1_input
     /sys/class/hwmon/hwmon2/temp1_input
     /sys/class/hwmon/hwmon2/temp2_input
     /sys/class/hwmon/hwmon2/temp3_input
     /sys/class/hwmon/hwmon4/temp1_input
     /sys/class/hwmon/hwmon4/temp2_input
     /sys/class/hwmon/hwmon4/temp3_input
     /sys/class/hwmon/hwmon4/temp4_input
     /sys/class/hwmon/hwmon4/temp5_input
     /sys/class/hwmon/hwmon4/temp6_input
     /sys/class/hwmon/hwmon4/temp7_input
     /sys/class/hwmon/hwmon4/temp8_input
     /sys/class/hwmon/hwmon6/temp1_input
     /sys/class/hwmon/hwmon8/temp1_input
     /sys/class/hwmon/hwmon8/temp2_input
     /sys/class/hwmon/hwmon8/temp3_input
     /sys/class/hwmon/hwmon8/temp4_input
     /sys/class/hwmon/hwmon8/temp5_input

There are working temperature sensors out of the box for the CPU, wifi card, 
ACPI thermal zone, and extended sensors from thinkpad_acpi.

In my case, I'd like to get notifications in userspace when certain 
temperatures are reached.

So if I understood correctly, there's no way to dynamically configure 
temperature thresholds and get breach events even as root, even with the new 
netlink solution?

Thanks again for your help!

Chris

Re: Thermal notifications without setting thermal governor to userspace?

[Daniel Lezcano]

On 04/04/2022 19:17, Chris Down wrote:
> Daniel Lezcano writes:
>> Well on regular desktop, the thermal is managed under the hood by the 
>> firmware/hardware, few sensors are exported AFAICT. I don't think a 
>> thermal daemon would have a benefit on these platforms.
> 
> Maybe we have different expectations? On my laptop, a Thinkpad T14s, 
> things seem not too bad:

That is not a desktop but a laptop, it is different :)

Can you give the content of:

cat /sys/class/thermal/thermal_zone*/type
cat /sys/class/thermal/thermal_zone*/trip_*type

and

cat /sys/class/thermal/cooling_device*/type

?


>      % printf '%s\n' /sys/class/hwmon/hwmon*/temp*_input
>      /sys/class/hwmon/hwmon1/temp1_input
>      /sys/class/hwmon/hwmon2/temp1_input
>      /sys/class/hwmon/hwmon2/temp2_input
>      /sys/class/hwmon/hwmon2/temp3_input
>      /sys/class/hwmon/hwmon4/temp1_input
>      /sys/class/hwmon/hwmon4/temp2_input
>      /sys/class/hwmon/hwmon4/temp3_input
>      /sys/class/hwmon/hwmon4/temp4_input
>      /sys/class/hwmon/hwmon4/temp5_input
>      /sys/class/hwmon/hwmon4/temp6_input
>      /sys/class/hwmon/hwmon4/temp7_input
>      /sys/class/hwmon/hwmon4/temp8_input
>      /sys/class/hwmon/hwmon6/temp1_input
>      /sys/class/hwmon/hwmon8/temp1_input
>      /sys/class/hwmon/hwmon8/temp2_input
>      /sys/class/hwmon/hwmon8/temp3_input
>      /sys/class/hwmon/hwmon8/temp4_input
>      /sys/class/hwmon/hwmon8/temp5_input
> 
> There are working temperature sensors out of the box for the CPU, wifi 
> card, ACPI thermal zone, and extended sensors from thinkpad_acpi.
> 
> In my case, I'd like to get notifications in userspace when certain 
> temperatures are reached.
> 
> So if I understood correctly, there's no way to dynamically configure 
> temperature thresholds and get breach events even as root, even with the 
> new netlink solution?

There is a way but you need:

1. A programmable trip point

 
https://uefi.org/specs/ACPI/6.4/11_Thermal_Management/thermal-control.html#dynamically-changing-cooling-temperature-trip-points

1.1 A passive trip point dedicated for userspace (no cooling device 
associated)

1.2 Writable kernel config option

The trip point will be writable in sysfs

2. Get trip point crossed

Use the netlink

But you don't need to monitor all these thermal zones, it is up to the 
in-kernel thermal framework to deal with the trip point individually and 
protect the system.

The userspace should monitor what is considered as the 'case' sensor or 
'skin' sensor. The temperature on those sensor moves very slowly, so 
monitoring them by getting the temperature every second should be enough.



-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: Thermal notifications without setting thermal governor to userspace?

[Chris Down]

Daniel Lezcano writes:
>On 04/04/2022 19:17, Chris Down wrote:
>>Daniel Lezcano writes:
>>>Well on regular desktop, the thermal is managed under the hood by 
>>>the firmware/hardware, few sensors are exported AFAICT. I don't 
>>>think a thermal daemon would have a benefit on these platforms.
>>
>>Maybe we have different expectations? On my laptop, a Thinkpad T14s, 
>>things seem not too bad:
>
>That is not a desktop but a laptop, it is different :)

Oh, I see :-) I misread the distinction as embedded vs. consumer-facing.

>Can you give the content of:
>
>cat /sys/class/thermal/thermal_zone*/type
>cat /sys/class/thermal/thermal_zone*/trip_*type
>
>and
>
>cat /sys/class/thermal/cooling_device*/type

   % grep . /sys/class/thermal/thermal_zone*/type
   /sys/class/thermal/thermal_zone0/type:acpitz
   /sys/class/thermal/thermal_zone1/type:INT3400 Thermal
   /sys/class/thermal/thermal_zone2/type:SEN1
   /sys/class/thermal/thermal_zone3/type:SEN2
   /sys/class/thermal/thermal_zone4/type:TCPU
   /sys/class/thermal/thermal_zone5/type:iwlwifi_1
   /sys/class/thermal/thermal_zone6/type:x86_pkg_temp
   % grep . /sys/class/thermal/thermal_zone*/trip_*type
   /sys/class/thermal/thermal_zone0/trip_point_0_type:critical
   /sys/class/thermal/thermal_zone2/trip_point_0_type:critical
   /sys/class/thermal/thermal_zone2/trip_point_1_type:hot
   /sys/class/thermal/thermal_zone2/trip_point_2_type:passive
   /sys/class/thermal/thermal_zone3/trip_point_0_type:critical
   /sys/class/thermal/thermal_zone3/trip_point_1_type:hot
   /sys/class/thermal/thermal_zone3/trip_point_2_type:passive
   /sys/class/thermal/thermal_zone4/trip_point_0_type:critical
   /sys/class/thermal/thermal_zone4/trip_point_1_type:hot
   /sys/class/thermal/thermal_zone4/trip_point_2_type:passive
   /sys/class/thermal/thermal_zone5/trip_point_0_type:passive
   /sys/class/thermal/thermal_zone5/trip_point_1_type:passive
   /sys/class/thermal/thermal_zone5/trip_point_2_type:passive
   /sys/class/thermal/thermal_zone5/trip_point_3_type:passive
   /sys/class/thermal/thermal_zone5/trip_point_4_type:passive
   /sys/class/thermal/thermal_zone5/trip_point_5_type:passive
   /sys/class/thermal/thermal_zone5/trip_point_6_type:passive
   /sys/class/thermal/thermal_zone5/trip_point_7_type:passive
   /sys/class/thermal/thermal_zone6/trip_point_0_type:passive
   /sys/class/thermal/thermal_zone6/trip_point_1_type:passive
   % grep . /sys/class/thermal/cooling_device*/type
   /sys/class/thermal/cooling_device0/type:Processor
   /sys/class/thermal/cooling_device1/type:Processor
   /sys/class/thermal/cooling_device2/type:Processor
   /sys/class/thermal/cooling_device3/type:Processor
   /sys/class/thermal/cooling_device4/type:Processor
   /sys/class/thermal/cooling_device5/type:Processor
   /sys/class/thermal/cooling_device6/type:Processor
   /sys/class/thermal/cooling_device7/type:Processor
   /sys/class/thermal/cooling_device8/type:intel_powerclamp
   /sys/class/thermal/cooling_device9/type:TCC Offset

>
>?
>
>
>>     % printf '%s\n' /sys/class/hwmon/hwmon*/temp*_input
>>     /sys/class/hwmon/hwmon1/temp1_input
>>     /sys/class/hwmon/hwmon2/temp1_input
>>     /sys/class/hwmon/hwmon2/temp2_input
>>     /sys/class/hwmon/hwmon2/temp3_input
>>     /sys/class/hwmon/hwmon4/temp1_input
>>     /sys/class/hwmon/hwmon4/temp2_input
>>     /sys/class/hwmon/hwmon4/temp3_input
>>     /sys/class/hwmon/hwmon4/temp4_input
>>     /sys/class/hwmon/hwmon4/temp5_input
>>     /sys/class/hwmon/hwmon4/temp6_input
>>     /sys/class/hwmon/hwmon4/temp7_input
>>     /sys/class/hwmon/hwmon4/temp8_input
>>     /sys/class/hwmon/hwmon6/temp1_input
>>     /sys/class/hwmon/hwmon8/temp1_input
>>     /sys/class/hwmon/hwmon8/temp2_input
>>     /sys/class/hwmon/hwmon8/temp3_input
>>     /sys/class/hwmon/hwmon8/temp4_input
>>     /sys/class/hwmon/hwmon8/temp5_input
>>
>>There are working temperature sensors out of the box for the CPU, 
>>wifi card, ACPI thermal zone, and extended sensors from 
>>thinkpad_acpi.
>>
>>In my case, I'd like to get notifications in userspace when certain 
>>temperatures are reached.
>>
>>So if I understood correctly, there's no way to dynamically 
>>configure temperature thresholds and get breach events even as root, 
>>even with the new netlink solution?
>
>There is a way but you need:
>
>1. A programmable trip point
>
>
>https://uefi.org/specs/ACPI/6.4/11_Thermal_Management/thermal-control.html#dynamically-changing-cooling-temperature-trip-points
>
>1.1 A passive trip point dedicated for userspace (no cooling device 
>associated)
>
>1.2 Writable kernel config option
>
>The trip point will be writable in sysfs
>
>2. Get trip point crossed
>
>Use the netlink
>
>But you don't need to monitor all these thermal zones, it is up to the 
>in-kernel thermal framework to deal with the trip point individually 
>and protect the system.
>
>The userspace should monitor what is considered as the 'case' sensor 
>or 'skin' sensor. The temperature on those sensor moves very slowly, 
>so monitoring them by getting the temperature every second should be 
>enough.

I see. I suspect this is probably too much to get from a distro kernel and 
myriad hardware, so I guess I'm consigned to using polling for the timebeing 
then.

Thanks a lot for chiming in with your knowledge :-)

Chris