|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [RFC] DVFS and Thermal management subsystem proposal
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?
> # 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)?
Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |