Re: [RFC] DVFS and Thermal management subsystem proposal

[Oleksii Moisieiev <Oleksii_Moisieiev@xxxxxxxx>]

Hi Jan,

On Thu, Jul 07, 2022 at 01:55:30PM +0200, Jan Beulich wrote:
> On 07.07.2022 12:35, Oleksii Moisieiev wrote:
> > # Synopsis
> > This document is intended to describe the design of the thermal based cpu
> > throttling in virtualized environments. The goal is to provide generic 
> > thermal
> > management subsystem, which should work with existing cpufreq subsystem in 
> > XEN
> > and could be used on various architectures and hardware.
> 
> Looks quite plausible to me, just two questions:
> 
> > # Cpufreq subsystem in XEN
> > 
> > ## Brief overview
> > 
> >    Governors
> > +--------------------+
> > | +----------------+ |  struct cpufreq_governor {
> > | |  ondemand      | |      .name
> > | +----------------+ |      .governor
> > | +----------------+ |      .handle_option
> > | |  powersave     | |  }
> > | +----------------+ |
> > | +----------------+ |                              +----------------------+
> > | |  performance   | |->cpufreq_register_governor() | +-------------------+|
> > | +----------------+ |                              | |  cpufreq_dev_drv  ||
> > | +----------------+ |   cpufreq_register_driver()->| +-------------------+|
> > | |  userspace     | |                              | +-------------------+|
> > | +----------------+ |                              | |     ...           ||
> > | +----------------+ |                              | +-------------------+|
> > | |  ...           | |    struct cpufreq_driver {   +----------------------+
> > | +----------------+ |       .init                  +----------------------+
> > +--------------------+       .verify                |    Hardware          |
> >                              .setpolicy             +----------------------+
> >                              .update
> >                              .target
> >                              .get
> >                              .getavg
> >                              .exit
> >                           }
> > 
> > Cpufreq subsystem consists of 2 parts:
> > 1) Cpufreq governor, which should be registered using 
> > cpufreq_register_governor
> > call;
> > 2) Cpufreq driver, which provides access to the hardware should be 
> > registered
> > using cpufreq_register_driver call.
> > 
> > ## Hardware drivers
> > 
> > There are two Cpufreq hardware drivers implemented by us (see Appendix 1 and
> > Appendix 2) to provide support for Rcar-3 and i.MX8 boards. Those drivers 
> > are
> > designed to support thermal throttling subsystem. They are going to be the 
> > part
> > of the contribution package.
> 
> Are these drivers also intended to act as "ordinary" cpufreq drivers,
> i.e. controlled by cpufreq governors instead of thermal ones?
> 

The idea is that cpufreq drivers acts as ordinary cpufreq drivers,
controlled by cpufreq governors if temperature is fine. But cpufreq opp
level can be overriden by thermal subsystem if critical or passive
temperature was reached.

> > # XEN Dynamic Thermal management design
> > 
> > ## Synopsis
> > 
> > Introducing the design of the Dynamic Thermal Management for Xen hypervisor.
> > This feature is an enhancement of the Xen DVFS feature and will allow system
> > admin to configure different thermal governors which will perform CPU
> > throttling, based on the CPU cores temperature and thermal configuration.
> > 
> > ## Top level design.
> > 
> > +-----------------------------------------------+
> > |    XEN                                        |
> > |              +-------------------+            |
> > |              |      Thermal      |            |
> > |       +----->|     Governor      |            |
> > |       |      +---------|---------+            |
> > |       |                |                      |
> > |       |                +-------+              |
> > |       |                        |              |
> > |  +------------------+  +------------------+   |
> > |  |   Thermal        |  |    Cpufreq       |   |
> > |  |   Driver         |  |                  |   |
> > |  +------------------+  +------------------+   |
> > |                                               |
> > +-----------------------------------------------+
> >                     ^
> >                     |
> >                     |
> >            +--------v--------+
> >            |                 |
> >            |    Hardware     |
> >            |                 |
> >            +-----------------+
> > 
> > 
> > ## Thermal management subsystem design in XEN
> > 
> >  +------------------+
> >  | +--------------+ |
> >  | |  powersave   | |               struct thermal_governor {
> >  | +--------------+ |                   .name
> >  | +--------------+ |                   .governor
> >  | |   stepwise   | |<------------+     .handle_option
> >  | +--------------+ |             | }
> >  | +--------------+ |             |
> >  | |     ...      | |             |
> >  | +--------------+ |             |
> >  +------------------+             v
> >           +----------------->register_thermal_governor()
> >           |
> > +---------v--------+                         Polling temperature
> > |   dyn_thermal    |<--------+             +--------------------+
> > +------------------+         +------------>|  polling_handler() |
> >                                            +--------------------+
> 
> Polling (only)?
> 
Here I described "worst" scenario when HW do not support IRQ in case of
alert. Both Rcar-3 and i.MX8 patforms have alerts so drivers will use
irq handlers to do throttling.

Best regards,
Oleksii.