Re: [CfP] Power Management and Thermal Control MC (LPC2023)

From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>,
	Linux PM <linux-pm@vger.kernel.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
	Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	"Zhang, Rui" <rui.zhang@intel.com>,
	Lukasz Luba <lukasz.luba@arm.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Morten Rasmussen <morten.rasmussen@arm.com>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Mario Limonciello <mario.limonciello@amd.com>
Subject: Re: [CfP] Power Management and Thermal Control MC (LPC2023)
Date: Wed, 24 May 2023 10:06:30 +0200	[thread overview]
Message-ID: <745b8b17-af4d-e8e1-83c1-89d600e7cd19@linaro.org> (raw)
In-Reply-To: <CAJZ5v0juUuy2xKZHMXAKSRtfQxMyL6z12AFdU8_ZbdFRKKrR=Q@mail.gmail.com>

On 22/05/2023 19:12, Rafael J. Wysocki wrote:
> Hi Folks,
> 
> I'm going to submit a Power Management and Thermal Control
> micro-conference proposal for LPC2023 along the lines of what happened
> in the previous iterations of it.
> 
> If you have topics that you'd like to be discussed there, please let
> me know by Friday, May 26.
> 
> Please note that LPC MC topics are expected to cover work in progress
> or at the concept stage.  They are not supposed to be about work that
> has been done already.

* Create a relevant debugfs thermal infrastructure + cleanup the sysfs 
debug related information.
    -> average temperature (overall / moving)
    -> mitigation episodes (duration, temperature max, min, avg, average 
performance througput)
    -> thermal zone behavior (temperature slope dT/dt vs performance 
througput)
    -> more TBD at LPC

[ RFC series ready but depends on the generic trip point ]

* New thermal trip types. Currently we have 'hot', 'passive', 'active', 
'critical' trip points. The userspace needs to deal with the thermal 
also but in a different manner. Currently, it has to poll the thermal 
zone to get the temperature, thus introducing more wakes up on the 
system. However the sensors have now a programmable register to trigger 
an interrupt and the userspace may benefit that. By adding one or 
several writable 'custom' trip points, the userspace can program a point 
to be notified and do an action. So we separate the actions from the 
kernel to protect the silicon and the ones from userspace to manage the 
overall thermal behavior in the system at lower temperatures.

[ depends on the generic trip points ]

* Thermal management without the time dimension taken into account is 
too simplistic. Add this dimension in the thermal information for better 
decision (eg. notification when a temperature is above a temperature 
after a duration)

* Improve the step wise governor. The step wise governor may take too 
much time to react when there are many cooling device states as it will 
increment with one step at each update (eg. idle cooling device has 100 
states). That may result on overshoots. Depending on the temperature 
slope we should increase the number of steps for the cooling action. The 
result should be some kind of PID regulation loop but simplified 
regarding the power allocator.

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