Thermal kernel events API to userspace - Was: Re: thermal: Avoid CONFIG_NET compile dependency

Thermal kernel events API to userspace - Was: Re: thermal: Avoid CONFIG_NET compile dependency

[Thomas Renninger]

Hi,

I wonder whether netlink is the way to go for thermal
events at all.
Sending an udev event would already contain the sysfs
path to the thermal device. A variable which thermal event
got thrown could get added and userspace can read out the rest
easily from sysfs files. But I expect udev is not intended
for such general events?

There is a lot talking about perf events...
perf events are/were for debugging as they get exported
through /sys/kernel/debug.
Recently people came up with the idea to add a perf event API
for MCE (Machine Check Exceptions) events which clearly is nothing
for debugging, but productive applications want to catch
and process them.
So either MCEs should better get a kind of netlink/ioctl or
whatever (not depending on debugging) interface to userspace
or thermal events might also fit as perf events.

This should get discussed by a broader audience, adding some
people to CC.

    Thomas


On Monday, January 24, 2011 11:35:23 AM Thomas Renninger wrote:
> Hi,
> 
> On Monday, January 24, 2011 05:39:26 AM R, Durgadoss wrote:
> > Hi Rui,
> > 
> ...
> > This refers to the patch that you acknowledged.
> > So, you are not missing any patch in the middle.
> > 
> > Also, the thermal_aux0 and _aux1, we can use the final format specified by you.
> > enum events {
> >  	THERMAL_CRITICAL,
> >  	/* user defined thermal events */
> >  	THERMAL_USER_AUX0,
> >  	THERMAL_USER_AUX1,
> >  	THERMAL_DEV_FAULT,
> >  };
> Something else...
> I've now seen your HW specific core/pkg temp threshold support.
> I didn't look at it that closely, but if you introduce generic
> thermal netlink events in the thermal driver those should match
> all kind of possible thermal events, not only the once introduced
> by the driver you added.
> 
> For example it would be great to get the ACPI specific thermal
> events which are currently exported as ACPI driven ones:
> drivers/acpi/thermal.c:acpi_thermal_notify()
> integrated there as well. So there should also be events like:
> >  	THERMAL_CRITICAL,
> >  	/* user defined thermal events */
> >  	THERMAL_USER_AUX0,
> >  	THERMAL_USER_AUX1,
> >  	THERMAL_DEV_FAULT,
> THERMAL_PASSIVE
> THERMAL_ACTIVE
> THERMAL_HOT
> 
> At some point of time we should be able
> to get rid of the ACPI specific thermal events at all?
> There seem to be nothing like a kind of
> "available netlink events and their format" API in Documentation.
> Each driver seem to do this and document it itself.
> But as it is an interface to userspace, these thermal netlink events
> should get documented in:
> Documentation/thermal
> 
> Currently you only export one of the above 4 thermal events as a
> number via netlink, right?
> Are there any userspace programs you have in mind which should make
> use of it?
> 
> Some data which should get exported as well:
>    - The temperature if available
>    - The number of the thermal zone, e.g. if 0, userspace can look
>      up sysfs for further info in:
>      /sys/devices/virtual/thermal/thermal_zone0/*
>    - The trip point affected if any, e.g. if 0, userspace can look it up
>      in sysfs for further info:
>      /sys/devices/virtual/thermal/thermal_zone0/trip_point_0_{temp,type}
>    - more?
> 
> Ehh, this core and package thermal driver you added threshold support,
> does this somehow register as a thermal driver?
> I can see that it registers for hwmon: hwmon_device_register(&pdev->dev);
> But is it somehow connected to thermal_sys.c other than that it just
> throws your newly introduced thermal_netlink_events?
> This driver should first register as a thermal driver, export
> trip points to:
> /sys/devices/virtual/thermal/thermal_zone0/trip_point_0_{temp,type}
> e.g.
> cat trip_point_0_type
> critical
> cat trip_point_1_type
> user_aux0
> 
> The thermal_netlink_events could then only be declared for
> thermal_sys.c scope, so that other drivers cannot misuse them
> and the netlink event can then get triggered by the driver through
> thermal driver callbacks.
> 
> Rui: What do you think?
> This implementation looks much too static, could you help to better
> adjust it to the generic thermal driver needs, you know this stuff best.
> 
> This is merged already. I wonder whether we still could get a thermal
> event netlink API for 2.6.38 which is more robust so that userspace does
> not need to differ its version with the next kernel.
> Maybe it's best to remove the thermal netlink parts again for now.
> 
> 
>      Thomas

Re: Thermal kernel events API to userspace - Was: Re: thermal: Avoid CONFIG_NET compile dependency

[Henrique de Moraes Holschuh]

On Mon, 24 Jan 2011, Thomas Renninger wrote:
> I wonder whether netlink is the way to go for thermal
> events at all.
> Sending an udev event would already contain the sysfs
> path to the thermal device. A variable which thermal event
> got thrown could get added and userspace can read out the rest
> easily from sysfs files. But I expect udev is not intended
> for such general events?

udev is heavyweight in the userspace side, we'd be much better off using the
ACPI event interface (which is netlink), or a new one to deliver system
status events, instead of continously abusing udev for this stuff.

> > > Also, the thermal_aux0 and _aux1, we can use the final format specified by you.
> > > enum events {
> > >  	THERMAL_CRITICAL,
> > >  	/* user defined thermal events */
> > >  	THERMAL_USER_AUX0,
> > >  	THERMAL_USER_AUX1,
> > >  	THERMAL_DEV_FAULT,
> > >  };

Please give us at least two levels of thermal alarm: critical and emergency
(or warning and critical -- it doesn't matter much, as long as there are at
least two levels, and which one comes first is defined by the
specification).  I'd have immediate use for them on thinkpads.

It is probably best to have three levels (warning, critical, emergency).
Best not to tie the API/ABI to the notion of "too hot", one can also alarm
when it starts to get to cold.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Thermal kernel events API to userspace - Was: Re: thermal: Avoid CONFIG_NET compile dependency

[Zhang Rui]

On Tue, 2011-01-25 at 00:07 +0800, Henrique de Moraes Holschuh wrote:
> On Mon, 24 Jan 2011, Thomas Renninger wrote:
> > I wonder whether netlink is the way to go for thermal
> > events at all.
> > Sending an udev event would already contain the sysfs
> > path to the thermal device. A variable which thermal event
> > got thrown could get added and userspace can read out the rest
> > easily from sysfs files. But I expect udev is not intended
> > for such general events?
> 
> udev is heavyweight in the userspace side, we'd be much better off using the
> ACPI event interface (which is netlink), or a new one to deliver system
> status events, instead of continously abusing udev for this stuff.
> 
> > > > Also, the thermal_aux0 and _aux1, we can use the final format specified by you.
> > > > enum events {
> > > >  	THERMAL_CRITICAL,
> > > >  	/* user defined thermal events */
> > > >  	THERMAL_USER_AUX0,
> > > >  	THERMAL_USER_AUX1,
> > > >  	THERMAL_DEV_FAULT,
> > > >  };
> 
> Please give us at least two levels of thermal alarm: critical and emergency
> (or warning and critical -- it doesn't matter much, as long as there are at
> least two levels, and which one comes first is defined by the
> specification).  I'd have immediate use for them on thinkpads.
> 
> It is probably best to have three levels (warning, critical, emergency).
> Best not to tie the API/ABI to the notion of "too hot", one can also alarm
> when it starts to get to cold.
> 
when it's the "too hot" case, what kind of action should be taken upon
the warning/critical/emergency events?
I mean what's the difference between these three levels.

thanks,
rui

Re: Thermal kernel events API to userspace - Was: Re: thermal: Avoid CONFIG_NET compile dependency

[Thomas Renninger]

On Tuesday, January 25, 2011 08:57:49 AM Zhang Rui wrote:
> On Tue, 2011-01-25 at 00:07 +0800, Henrique de Moraes Holschuh wrote:
> > On Mon, 24 Jan 2011, Thomas Renninger wrote:
> > > I wonder whether netlink is the way to go for thermal
> > > events at all.
> > > Sending an udev event would already contain the sysfs
> > > path to the thermal device. A variable which thermal event
> > > got thrown could get added and userspace can read out the rest
> > > easily from sysfs files. But I expect udev is not intended
> > > for such general events?
> > 
> > udev is heavyweight in the userspace side, we'd be much better off using the
> > ACPI event interface (which is netlink), or a new one to deliver system
> > status events, instead of continously abusing udev for this stuff.
> > 
> > > > > Also, the thermal_aux0 and _aux1, we can use the final format specified by you.
> > > > > enum events {
> > > > >  	THERMAL_CRITICAL,
> > > > >  	/* user defined thermal events */
> > > > >  	THERMAL_USER_AUX0,
> > > > >  	THERMAL_USER_AUX1,
> > > > >  	THERMAL_DEV_FAULT,
> > > > >  };
> > 
> > Please give us at least two levels of thermal alarm: critical and emergency
> > (or warning and critical -- it doesn't matter much, as long as there are at
> > least two levels, and which one comes first is defined by the
> > specification).  I'd have immediate use for them on thinkpads.
What kind of thinkpad specific events are these and what actions
should be taken if they happen?
 
> > It is probably best to have three levels (warning, critical, emergency).
> > Best not to tie the API/ABI to the notion of "too hot", one can also alarm
> > when it starts to get to cold.
> > 
> when it's the "too hot" case, what kind of action should be taken upon
> the warning/critical/emergency events?
> I mean what's the difference between these three levels.
I could imagine there is quite some HW out there
with quite different thermal events.
What other actions userspace would take beside logging the event,
telling the user that a fan is switched on, CPU or whatever device
gets throttled. Logging such specific info can only be implemented
in the driver itself and would get lost when exporting things through
a generic thermal interface.

I wonder which events would need userspace to take specific
(configured) actions at all and what kind of action it could be.

What is THERMAL_USER_AUX0?
When will it get thrown and what is userspace expected to do?

    Thomas

Re: Thermal kernel events API to userspace - Was: Re: thermal: Avoid CONFIG_NET compile dependency

[Henrique de Moraes Holschuh]

On Tue, 25 Jan 2011, Thomas Renninger wrote:
> > > Please give us at least two levels of thermal alarm: critical and emergency
> > > (or warning and critical -- it doesn't matter much, as long as there are at
> > > least two levels, and which one comes first is defined by the
> > > specification).  I'd have immediate use for them on thinkpads.
> What kind of thinkpad specific events are these and what actions
> should be taken if they happen?

So far:  Battery temperature critical and emergency, Generic system sensor
temperature critical and emergency.

In all cases, the recommended actions are imediate notification for the
user, and in the case of the emergency level, immediate action, where action
is "suspend to ram" or shutdown.

Right now all they do is to prinkt at suitable "horrible things are about to
happen" severity levels (KERN_CRIT for critical, and KERN_ALERT for
emergency).  In a few sensible desktop environments and distros, this causes
a notification to show up on the user's screen.

Oh, and it also relays the thinkpad-specific event through the ACPI event
pipe, but I don't know of any userspace application doing something with it,
and nobody ever tried to bribe me into writing one by suppling me with a new
T-series thinkpad :)

> I wonder which events would need userspace to take specific
> (configured) actions at all and what kind of action it could be.

All of them can have sensible generic actions.  See my other email.

> What is THERMAL_USER_AUX0?
> When will it get thrown and what is userspace expected to do?

Good question.  What use are those "user defined" events in a generic
interface, anyway?  You will have to know exactly what device is issuing the
"generic user defined" event, and what it means for that device.

When you need a device-specific interface, you design one that is well
defined, such as thinkpad-acpi's thinkpad-specific "acpi" events.  If you
get any thinkpad-acpi specific event, you know exactly what it is, and
nothing else ever issues those events, so you will never get them from
somewhere else with a different meaning.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

RE: Thermal kernel events API to userspace - Was: Re: thermal: Avoid CONFIG_NET compile dependency

[Zhang, Rui]

> -----Original Message-----
> From: Henrique de Moraes Holschuh [mailto:hmh@hmh.eng.br]
> Sent: Wednesday, January 26, 2011 12:11 AM
> To: Thomas Renninger
> Cc: Zhang, Rui; R, Durgadoss; jdelvare@novell.com; Len Brown; linux-
> acpi@vger.kernel.org; Kay Sievers; linux-perf-users@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-trace-users@vger.kernel.org
> Subject: Re: Thermal kernel events API to userspace - Was: Re: thermal:
> Avoid CONFIG_NET compile dependency
> Importance: High
> 
> On Tue, 25 Jan 2011, Thomas Renninger wrote:
> > > > Please give us at least two levels of thermal alarm: critical and
> emergency
> > > > (or warning and critical -- it doesn't matter much, as long as
> there are at
> > > > least two levels, and which one comes first is defined by the
> > > > specification).  I'd have immediate use for them on thinkpads.
> > What kind of thinkpad specific events are these and what actions
> > should be taken if they happen?
> 
> So far:  Battery temperature critical and emergency, Generic system
> sensor
> temperature critical and emergency.
> 
> In all cases, the recommended actions are imediate notification for the
> user, and in the case of the emergency level, immediate action, where
> action
> is "suspend to ram" or shutdown.
> 
> Right now all they do is to prinkt at suitable "horrible things are
> about to
> happen" severity levels (KERN_CRIT for critical, and KERN_ALERT for
> emergency).  In a few sensible desktop environments and distros, this
> causes
> a notification to show up on the user's screen.
> 
> Oh, and it also relays the thinkpad-specific event through the ACPI
> event
> pipe, but I don't know of any userspace application doing something
> with it,
> and nobody ever tried to bribe me into writing one by suppling me with
> a new
> T-series thinkpad :)
> 
> > I wonder which events would need userspace to take specific
> > (configured) actions at all and what kind of action it could be.
> 
> All of them can have sensible generic actions.  See my other email.
> 
> > What is THERMAL_USER_AUX0?
> > When will it get thrown and what is userspace expected to do?
> 
> Good question.  What use are those "user defined" events in a generic
> interface, anyway?  You will have to know exactly what device is
> issuing the
> "generic user defined" event, and what it means for that device.
> 
> When you need a device-specific interface, you design one that is well
> defined, such as thinkpad-acpi's thinkpad-specific "acpi" events.  If
> you
> get any thinkpad-acpi specific event, you know exactly what it is, and
> nothing else ever issues those events, so you will never get them from
> somewhere else with a different meaning.
>
I think you are talking about something like this:
enum events {
	/* generic thermal event */
	THERMAL_WARN,
	THERMAL_EMERG,
	THERMAL_CRIT,
	/* coretemp thermal events */
	TEHRMAL_CT_AUX0,
	TEHRMAL_CT_AUX1,
	/* Thinkpad battery thermal events */
	THERMAL_TP_BAT_CRIT,
	THERMAL_TP_BAT_EMERG,
	THERMAL_DEV_FAULT,
};
Right?


> --
>   "One disk to rule them all, One disk to find them. One disk to bring
>   them all and in the darkness grind them. In the Land of Redmond
>   where the shadows lie." -- The Silicon Valley Tarot
>   Henrique Holschuh

Re: Thermal kernel events API to userspace - Was: Re: thermal: Avoid CONFIG_NET compile dependency

[Henrique de Moraes Holschuh]

On Wed, 26 Jan 2011, Zhang, Rui wrote:
> > > I wonder which events would need userspace to take specific
> > > (configured) actions at all and what kind of action it could be.
> > 
> > All of them can have sensible generic actions.  See my other email.
> > 
> > > What is THERMAL_USER_AUX0?
> > > When will it get thrown and what is userspace expected to do?
> > 
> > Good question.  What use are those "user defined" events in a generic
> > interface, anyway?  You will have to know exactly what device is
> > issuing the
> > "generic user defined" event, and what it means for that device.
> > 
> > When you need a device-specific interface, you design one that is well
> > defined, such as thinkpad-acpi's thinkpad-specific "acpi" events.  If
> > you
> > get any thinkpad-acpi specific event, you know exactly what it is, and
> > nothing else ever issues those events, so you will never get them from
> > somewhere else with a different meaning.
> >
> I think you are talking about something like this:
> enum events {
> 	/* generic thermal event */
> 	THERMAL_WARN,
> 	THERMAL_EMERG,
> 	THERMAL_CRIT,
> 	/* coretemp thermal events */
> 	TEHRMAL_CT_AUX0,
> 	TEHRMAL_CT_AUX1,
> 	/* Thinkpad battery thermal events */
> 	THERMAL_TP_BAT_CRIT,
> 	THERMAL_TP_BAT_EMERG,
> 	THERMAL_DEV_FAULT,
> };
> Right?

Hmm, no.  I already perfectly fine, strictly defined driver-specific events.
And driver-specific events are useless crap in practice.  Nobody really
codes userspace utilities for them.  Maybe some 10-20 power users write ACPI
rules and scripts to deal with them, but that's it.

I am quite willing and happy to keep the driver-specific events for those 20
people in the world that actually used them to make something nice, and even
add new ones when necessary.  But that is NOT the way to go forward when
you have any sort of choice.

I.e.  I'd like THERMAL_BAT_CRIT, THERMAL_BAT_EMERG, and a strict enough
definition of what they mean, that userspace (or a kernel thermal event
handler) could process them and do the right thing regardless of which
driver generated the events, because it would be sure of what they mean.

You might want to change that to a two-axis or three-axis event, actually:

What:   THERMAL_NORMAL, THERMAL_WARN, THERMAL_EMERG, THERMAL_CRIT,
        THERMAL_SENSOR_FAULT...

Where:  SYSTEM (aka: unknown/generic), BATTERY, CPU, GPU, PSU, PCIDEV, USBDEV...

Extended code: (what,where)-specific.  For example, could be the specific
core or package for (*, CPU) events...

BTW: thermal_normal means "alarm condition cleared".  Like thermal_warn, I
wouldn't expect every device to be able to raise it.  Thinkpads, for
example, won't tell you when they're back to normal operating conditions
AFAIK.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Thermal kernel events API to userspace - Was: Re: thermal: Avoid CONFIG_NET compile dependency

[Henrique de Moraes Holschuh]

On Tue, 25 Jan 2011, Zhang Rui wrote:
> On Tue, 2011-01-25 at 00:07 +0800, Henrique de Moraes Holschuh wrote:
> > > > > Also, the thermal_aux0 and _aux1, we can use the final format specified by you.
> > > > > enum events {
> > > > >  	THERMAL_CRITICAL,
> > > > >  	/* user defined thermal events */
> > > > >  	THERMAL_USER_AUX0,
> > > > >  	THERMAL_USER_AUX1,
> > > > >  	THERMAL_DEV_FAULT,
> > > > >  };
> > 
> > Please give us at least two levels of thermal alarm: critical and emergency
> > (or warning and critical -- it doesn't matter much, as long as there are at
> > least two levels, and which one comes first is defined by the
> > specification).  I'd have immediate use for them on thinkpads.
> > 
> > It is probably best to have three levels (warning, critical, emergency).
> > Best not to tie the API/ABI to the notion of "too hot", one can also alarm
> > when it starts to get to cold.
> > 
> when it's the "too hot" case, what kind of action should be taken upon
> the warning/critical/emergency events?
> I mean what's the difference between these three levels.

*ASSUMING* it is monitoring the box (which is a damn big assumption, and
should be stated outright):

Warning: do something to stop generating so much heat, warn user, try to
increase cooling.  Let userspace bother with this.

Critical: *STOP* generating so much heat (throttle cpu, throttle GPU,
shutdown non-critical devices, etc).  Increase cooling to max.  WARN the
user that a machine emergency exists and shutdown is imminent, and that he
has to power off or sleep to ram *NOW*.

Emergency: emergency sync, and initiate immediate suspend to ram. If that
fails, initiate emergency powerdown.

Likely one wants kernel notifiers for this stuff, too, so that we can have
in-kernel handlers (optional or not, configurable or not, that is orthogonal
to the issue) that can try to do something to help.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

RE: Thermal kernel events API to userspace - Was: Re: thermal: Avoid CONFIG_NET compile dependency

[R, Durgadoss]

Hi Thomas,

> 
> I wonder which events would need userspace to take specific
> (configured) actions at all and what kind of action it could be.
> 
> What is THERMAL_USER_AUX0?
> When will it get thrown and what is userspace expected to do?
> 

This THERMAL_USER_AUX0 is meant for the DTS core thresholds.
In ACPI compliant systems, There are two core thresholds, that
Can be programmed and read via IA32_THERM_INTERRUPT MSR. One is the
Lower threshold (AUX0) and the other one is the higher threshold(AUX1).

When the Current temperature goes below the lower threshold, or above
the higher threshold, the HW generates an interrupt. This is what is
forwarded to the user space through the netlink events.

The user app can increase performance(increase CPU speed..)
on receiving AUX0 events, and try to reduce performance
(like CPU frequency reduction, display control..)on getting AUX1 events.
Basically, the app can do anything to reduce the temperature of the
Platform.

Thanks,
Durga