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

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

[Rafael J. Wysocki]

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.

Kind regards,
Rafael

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

[Lukasz Luba]

Hi Rafael,

On 5/22/23 18: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.

Sounds good. What would be the time slot for one presentation?

Regards,
Lukasz

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

[Rafael J. Wysocki]

Hi Lukasz,

On Mon, May 22, 2023 at 7:52 PM Lukasz Luba <lukasz.luba@arm.com> wrote:
>
> Hi Rafael,
>
> On 5/22/23 18: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.
>
> Sounds good. What would be the time slot for one presentation?

That depends on the number of topics.  Usually it has been around 25 -
30 minutes.

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

[srinivas pandruvada]

Hi Rafael,

On Mon, 2023-05-22 at 19:12 +0200, 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.
"
1.
Idle injection and soft IRQs:
We still have no good solution to avoid races with soft IRQ scheduling
while using idle injection. The previous post to kernel to solve this
issue is rejected. Peter proposed a change, that also didn't work.

I am proposing a discussion on how the solve this:
- May be we need to use some in kernel IRQ affinity change for the
forced idle CPUs
- Other potential solution?

"

2.
Thermal sysfs/API Update

Thermal sysfs v2
There was proposal to correctly abstract thermal zones, sensors,
cooling devices and policies. Are we happy with the current state?

- Add capability to define additional private attributes for a zone
like cpufreq

Thanks,
Srinivas

> 
> Kind regards,
> Rafael

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

[Rafael J. Wysocki]

Hi Srinivas,

On Tue, May 23, 2023 at 12:34 AM srinivas pandruvada
<srinivas.pandruvada@linux.intel.com> wrote:
>
> Hi Rafael,
>
> On Mon, 2023-05-22 at 19:12 +0200, 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.
> "
> 1.
> Idle injection and soft IRQs:
> We still have no good solution to avoid races with soft IRQ scheduling
> while using idle injection. The previous post to kernel to solve this
> issue is rejected. Peter proposed a change, that also didn't work.
>
> I am proposing a discussion on how the solve this:
> - May be we need to use some in kernel IRQ affinity change for the
> forced idle CPUs
> - Other potential solution?
>
> "
>
> 2.
> Thermal sysfs/API Update
>
> Thermal sysfs v2
> There was proposal to correctly abstract thermal zones, sensors,
> cooling devices and policies. Are we happy with the current state?
>
> - Add capability to define additional private attributes for a zone
> like cpufreq

Good topics both, thanks!

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

[Zhang, Rui]

Hi, Rafael,

On Mon, 2023-05-22 at 19:12 +0200, 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.

"intel_lpmd(Intel Low Power Mode Daemon)"

I'm developing a userspace tool which puts tasks on a group of most
power efficiency CPUs to save extra power in partial idle scenarios.

I'd like to take this chance to demonstrate how it works and get
further feedbacks.

thanks,
rui

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

[Daniel Lezcano]

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

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

[Rafael J. Wysocki]

On Wed, May 24, 2023 at 10:06 AM Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
>
> 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

Sounds good.

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

So this basically would be an interface for user space to add a trip
point at run time?

What about a "send me an event if the temperature is equal to this"
interface instead?

But yes, as a discussion topic this would be fine.

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

OK

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

Sounds good, but it is kind of minor with respect to the above.  We'll see.

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

[Daniel Lezcano]

On 24/05/2023 12:25, Rafael J. Wysocki wrote:
> On Wed, May 24, 2023 at 10:06 AM Daniel Lezcano
> <daniel.lezcano@linaro.org> wrote:
>>
>> 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
> 
> Sounds good.
> 
>> [ 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 ]
> 
> So this basically would be an interface for user space to add a trip
> point at run time?

I was thinking about a description like any other trip points. So they 
will be added in sysfs as trip_point_x_temp. The thermal framework will 
ensure the trip temperature is below the temperature of other trip 
points types.

> What about a "send me an event if the temperature is equal to this"
> interface instead?

If you add a writable trip point that is what the thermal framework will 
do. The idea is to clearly identify an 'userspace' trip point which will 
be writable, other types will stay read-only.


> But yes, as a discussion topic this would be fine.

Yeah, we can see that is already triggering a discussion here :)


>> * 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)
> 
> OK
> 
>> * 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.
> 
> Sounds good, but it is kind of minor with respect to the above.  We'll see.

No problem

Thanks!

   -- 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: [CfP] Power Management and Thermal Control MC (LPC2023)

[Sudeep Holla]

Hi Rafael,

On Mon, May 22, 2023 at 07:12:39PM +0200, 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.
> 

One topic I am thinking of is possible ACPI extensions for device DVFS
something similar to CPU CPPC which I think both x86 and Arm community
are interested. There are also bunch of topics for Arm based laptop like
devices which probably x86 don't have to deal with. I am not sure if 
LPC uconf is the right forum but since many of the topics are now driven
by code first approach, I thought of bringing it up here and see if there
is any interest.

Let me know what do you think.

-- 
Regards,
Sudeep

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

[Morten Rasmussen]

Hi Rafael,

Thanks for organizing the micro-conference at LPC again this year.

On Mon, May 22, 2023 at 07:12:39PM +0200, 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.

A late proposal, if the agenda isn't already full, is to discuss the
deeper implications of uclamp in CFS relating to fairness, latency, and
energy savings. uclamp is being adopted in the Android community for
controlling performance/energy savings but alignment with upstream is
lacking behind.

"uclamp in CFS: Fairness, latency, and energy efficiency."

Thanks,
Morten

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

[Vincent Guittot]

Hi Morten,

On Wed, 31 May 2023 at 12:16, Morten Rasmussen <morten.rasmussen@arm.com> wrote:
>
> Hi Rafael,
>
> Thanks for organizing the micro-conference at LPC again this year.
>
> On Mon, May 22, 2023 at 07:12:39PM +0200, 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.
>
> A late proposal, if the agenda isn't already full, is to discuss the
> deeper implications of uclamp in CFS relating to fairness, latency, and
> energy savings. uclamp is being adopted in the Android community for
> controlling performance/energy savings but alignment with upstream is
> lacking behind.

With Daniel, Juri and Steven, we have submitted a "Real-time and
Scheduling MC" which is not yet accepted (so it's not yet publicly
visible).  But this could be a better place to discuss CFS changes.

Regards,
Vincent

>
> "uclamp in CFS: Fairness, latency, and energy efficiency."
>
> Thanks,
> Morten

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

[Steven Rostedt]

On Wed, 31 May 2023 13:07:26 +0200
Vincent Guittot <vincent.guittot@linaro.org> wrote:

> With Daniel, Juri and Steven, we have submitted a "Real-time and
> Scheduling MC" which is not yet accepted (so it's not yet publicly
> visible).  But this could be a better place to discuss CFS changes.
> 

Thanks for bringing this to my attention. It seems that the Real-time
and Scheduling MC is the *only* MC that is not publicly visible in the
"Proposed Microconferences" section.

Let me go find out why.

-- Steve

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

[Steven Rostedt]

On Wed, 31 May 2023 08:00:12 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> Thanks for bringing this to my attention. It seems that the Real-time
> and Scheduling MC is the *only* MC that is not publicly visible in the
> "Proposed Microconferences" section.
> 
> Let me go find out why.

It's now visible.

https://lpc.events/event/17/page/200-proposed-microconferences

-- Steve

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

[Morten Rasmussen]

Hi Vincent,

On Wed, May 31, 2023 at 01:07:26PM +0200, Vincent Guittot wrote:
> Hi Morten,
> 
> On Wed, 31 May 2023 at 12:16, Morten Rasmussen <morten.rasmussen@arm.com> wrote:
> >
> > Hi Rafael,
> >
> > Thanks for organizing the micro-conference at LPC again this year.
> >
> > On Mon, May 22, 2023 at 07:12:39PM +0200, 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.
> >
> > A late proposal, if the agenda isn't already full, is to discuss the
> > deeper implications of uclamp in CFS relating to fairness, latency, and
> > energy savings. uclamp is being adopted in the Android community for
> > controlling performance/energy savings but alignment with upstream is
> > lacking behind.
> 
> With Daniel, Juri and Steven, we have submitted a "Real-time and
> Scheduling MC" which is not yet accepted (so it's not yet publicly
> visible).  But this could be a better place to discuss CFS changes.

That could work too. It is closely related to PM though as uclamp is
essentially putting the power/performance policy directly in the
scheduler. With the right people around it doesn't matter where it is
discussed :-)

Morten

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

[Vincent Guittot]

On Wed, 31 May 2023 at 14:09, Morten Rasmussen <morten.rasmussen@arm.com> wrote:
>
> Hi Vincent,
>
> On Wed, May 31, 2023 at 01:07:26PM +0200, Vincent Guittot wrote:
> > Hi Morten,
> >
> > On Wed, 31 May 2023 at 12:16, Morten Rasmussen <morten.rasmussen@arm.com> wrote:
> > >
> > > Hi Rafael,
> > >
> > > Thanks for organizing the micro-conference at LPC again this year.
> > >
> > > On Mon, May 22, 2023 at 07:12:39PM +0200, 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.
> > >
> > > A late proposal, if the agenda isn't already full, is to discuss the
> > > deeper implications of uclamp in CFS relating to fairness, latency, and
> > > energy savings. uclamp is being adopted in the Android community for
> > > controlling performance/energy savings but alignment with upstream is
> > > lacking behind.
> >
> > With Daniel, Juri and Steven, we have submitted a "Real-time and
> > Scheduling MC" which is not yet accepted (so it's not yet publicly
> > visible).  But this could be a better place to discuss CFS changes.
>
> That could work too. It is closely related to PM though as uclamp is
> essentially putting the power/performance policy directly in the
> scheduler. With the right people around it doesn't matter where it is
> discussed :-)

Probably depends of what you want to discuss indeed but the " in CFS "
triggers to me that it could implies scheduler changes

>
> Morten

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

[Rafael J. Wysocki]

Hi Morten,

On Wed, May 31, 2023 at 12:16 PM Morten Rasmussen
<morten.rasmussen@arm.com> wrote:
>
> Hi Rafael,
>
> Thanks for organizing the micro-conference at LPC again this year.
>
> On Mon, May 22, 2023 at 07:12:39PM +0200, 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.
>
> A late proposal, if the agenda isn't already full, is to discuss the
> deeper implications of uclamp in CFS relating to fairness, latency, and
> energy savings. uclamp is being adopted in the Android community for
> controlling performance/energy savings but alignment with upstream is
> lacking behind.

There will be a proper CfP just for the MC later I think (at least
that was the case previously), at this time it's just a collection of
topics.

> "uclamp in CFS: Fairness, latency, and energy efficiency."

OK, I'll add it.  It can be moved to the "RT and scheduling" MC later
or submitted there when the MCs get accepted.

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

[Ulf Hansson]

On Mon, 22 May 2023 at 19:12, Rafael J. Wysocki <rafael@kernel.org> 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.

If not too late, I can raise one potential topic for discussion.

I am hearing, mostly from the ARM community, that there are needs to
support multiple system wide low power states. Not only based upon
what system wakeups that need to be configured, but rather based upon
wakeup latency constraints required for certain use cases. s2idle can
be explored as a possibility to make this work, but I think a wider
discussion could be valuable.

Maybe this is something that can be valuable for the x86 community to
discuss too?

Kind regards
Uffe

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

[Rafael J. Wysocki]

Hi Folks,

It has been possible to submit micro-conference topics through the LPC
website for a while, so please take the time to submit your Power
Management and Thermal Control MC topic to allow the schedule to be
put together.

Thanks!

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

[Rafael J. Wysocki]

Hi Folks,

On Wed, Jul 19, 2023 at 7:15 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> It has been possible to submit micro-conference topics through the LPC
> website for a while, so please take the time to submit your Power
> Management and Thermal Control MC topic to allow the schedule to be
> put together.

Please submit all of the Power Management and Thermal Control MC
topics, if you have not done that yet, by the end of this week (August
27).  It will not be possible to submit any more topics to this MC
later.

Thanks!