Re: [PATCH v2 0/7] Add thermal thresholds support

["Pandruvada, Srinivas" <srinivas.pandruvada@intel.com>]

On Thu, 2024-08-22 at 19:08 +0200, Daniel Lezcano wrote:
> On 22/08/2024 14:11, Pandruvada, Srinivas wrote:
> > On Thu, 2024-08-22 at 11:41 +0200, Rafael J. Wysocki wrote:
> > > On Thu, Aug 22, 2024 at 12:16 AM Pandruvada, Srinivas
> > > <srinivas.pandruvada@intel.com> wrote:
> 
> [ ... ]
> 
> > > So did you apply the Daniel's patches and run the test or did you
> > > do
> > > something else?
> > We already use netlink to send notification to user space via
> > writable
> > trip. So didn't apply any patches. I don't see these patches will
> > do
> > any different.
> 
> Actually you are missing the point of the thresholds approach.

I very well understand. I proposed similar approach without netlink
several years back. Also submitted patches to use IIO.


> 
> The goal is to track the temperature easily from userspace without 
> constantly polling the temperatures in all the places.
> 
Exactly.


> The trip points are a firmware descriptions. Their number is fixed.
> They 
> are designed for in-kernel thermal framework. They have a type. A 
> governor is supposed to be tied with it. A cooling device also.
> 
Yes, I understand the whole approach. trips are trip where you want
governors to take action.

> Writable trip points means you should be able to add trip points 
> dedicated to the userspace to the firmware which is not possible.
> Then 
> reuse them from userspace which is unrelated to the in-kernel thermal
> management. It is difficult to deal with because of the need of
> tracking 
> the low and high limits from userspace.
> 
Yes.

> The thresholds are there to allow the userspace to have the benefit
> of 
> the interrupt driven temperature monitoring.
> 
Yes. I am not denying benefits.

> Obviously if you set the thresholds to a temperature equal to a 
> mitigation trip point then when the limit is reached you will receive
> notifications for the trip point going back and forth as well as 
> notifications for the thresholds.
> 
Not correct. It is not at mitigation point. This is how several sensors
several sensors work. I submitted a range of sensor drivers to IIO
framework, several have this issue.

To make it useful, you need to have some rate limiting. Netlink is not
a low overhead user-kernel interface.

Looks like you finalized design and just looking for patch reviews!


> 
> 
> 
>