Xen devel - Jul 2011 - Passive and Active ACPI Thermal control under Xen?

Hello,

With summer in full swing these days, I''ve been trying to somehow cool
down my laptop, which brought me into tinkering with various ACPI stuff,
and raised a few questions on how Xen and Dom0 cooperate to enforce
thermal policy.

I''m using Xen 4.1 booted *without* cpufreq=dom0-kernel and I can see
xenpm returning all the various info about my processors'' C and P
states. I can even set the policy, e.g.:

xenpm set-scaling-gov powersave

The only problem being it has absolutely zero impact on the system
temperature...

According to the ACPI spec, there are two primary methods for thermal
control of the platform: 1) active control and 2) passive control. The
former works by OSPM enabling various fans at different speeds,
depending on the measured temperatures from various sensors, while the
latter works by throttling down the CPU frequencies and perhaps by
controlling transitions to the deeper C states.

My understanding is that the cpufreq mechanism in Xen is essentially an
implementation of the passive thermal control? If this is so, does Xen
honor the ACPI-defined _TC1 and _TC2 constants (that one usually can set
in the BIOS)? I could imagine that this should be the correct behavior
when one selects the ''powersave'' governor, shouldn''t
it?

Next question relates to the active thermal control -- who is in charge
of spinning the fans? My understanding is that on a baremetal Linux,
this is the job of the thermal.ko module? (which also apparently should
take care about the passive control, although not when booted under Xen)

Unfortunately I cannot get my cooling fan to spin :( I tried setting the
temp thresholds in BIOS for when the fan should be spinning at low and
high speed (_AC0, _AC1), and even pass them directly to the thermal.ko
module (as ''act'' param), but my fan remain silent even though
I can see
the temperature going above the thresholds.

The only moment I can hear my fan spinning at full speed is during early
boot stage (I assume this is when the _AC0, _AC1 constants I set in BIOS
are actually honored by the SMI handler), but then, after booting into
Xen and Dom0 the fan is being turned off.

Xen 4.1.0, Dom0 kernel: 2.6.38 (xenlinux), platform: Sony Vaio Z12

Thanks,
joanna.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> From: Joanna Rutkowska
> Sent: Wednesday, July 13, 2011 11:32 PM
> 
> Hello,
> 
> With summer in full swing these days, I''ve been trying to somehow
cool
> down my laptop, which brought me into tinkering with various ACPI stuff,
> and raised a few questions on how Xen and Dom0 cooperate to enforce
> thermal policy.
> 
> I''m using Xen 4.1 booted *without* cpufreq=dom0-kernel and I can
see
> xenpm returning all the various info about my processors'' C and P
> states. I can even set the policy, e.g.:
> 
> xenpm set-scaling-gov powersave
> 
> The only problem being it has absolutely zero impact on the system
> temperature...
system temperature is influenced by all the components in the platform,
while xenpm just talks to Cstate/Pstate governors in Xen which only
control the behavior of the processors.
> 
> According to the ACPI spec, there are two primary methods for thermal
> control of the platform: 1) active control and 2) passive control. The
> former works by OSPM enabling various fans at different speeds,
> depending on the measured temperatures from various sensors, while the
> latter works by throttling down the CPU frequencies and perhaps by
> controlling transitions to the deeper C states.
> 
> My understanding is that the cpufreq mechanism in Xen is essentially an
> implementation of the passive thermal control? If this is so, does Xen
> honor the ACPI-defined _TC1 and _TC2 constants (that one usually can set
> in the BIOS)? I could imagine that this should be the correct behavior
> when one selects the ''powersave'' governor,
shouldn''t it?
Though all the processor power management activities by OSPM
could be considered as passive cooling:

	low power idle state (Cstate/cpuidle)
	frequency and voltage scaling (Pstate/cpufreq)
	clock throttling (Tstate)

, most time (at least in Linux/Xen world), passive cooling refers to Tstate
specifically. Normally cpuidle and cpufreq governors run independently
regardless of temperature factor, with the major goal to save power with
minimal performance impact, known as power efficiency. When temperature
is higher than passive cooling threshold, Tstate is triggered which absolutely
gating M clocks every N clocks, which hurts performance sharply but can
passively reduce CPU temperature effectively. 
>From implementation p.o.v, so far Xen only control C/P itself, instead
leaving
Tstate to dom0. The rationale is from Xen virtualization architecture,
that Xen owns CPU and memory while dom0 owns the rest of the platform.
Thermal control is tightly related to the platform, as you may see from ACPI
spec there could be multiple thermal zones with one of them include CPUs.
Regarding to this platform manner, it''s more natural to keep passive
cooling
policy within dom0. the implication is that you need have
"dom0_vcpus_pin"
enabled and leave dom0 with same #VCPU as #PCPU. Xen grants dom0 to
control related I/O ports for Tstate control, and this way passive cooling
on processor related thermal zone should work. this implication is not a
flexible approach, which may be reworked later. The only way Xen may 
touch Tstate is when critical trip point is reached which is reflected in a 
Local APIC interrupt.

For the rest of the platform thermal zones, it''s fully dom0''s
responsibility
which should be unchanged from bare metal Linux. 

> 
> Next question relates to the active thermal control -- who is in charge
> of spinning the fans? My understanding is that on a baremetal Linux,
> this is the job of the thermal.ko module? (which also apparently should
> take care about the passive control, although not when booted under Xen)
active thermal control is related to fans, which is owned by dom0. I''m
not
sure now whether thermal.ko is the only related module, but very likely 
it should be.
> 
> Unfortunately I cannot get my cooling fan to spin :( I tried setting the
> temp thresholds in BIOS for when the fan should be spinning at low and
> high speed (_AC0, _AC1), and even pass them directly to the thermal.ko
> module (as ''act'' param), but my fan remain silent even
though I can see
> the temperature going above the thresholds.
> 
> The only moment I can hear my fan spinning at full speed is during early
> boot stage (I assume this is when the _AC0, _AC1 constants I set in BIOS
> are actually honored by the SMI handler), but then, after booting into
> Xen and Dom0 the fan is being turned off.
> 
> Xen 4.1.0, Dom0 kernel: 2.6.38 (xenlinux), platform: Sony Vaio Z12
> 
I would suggest trying same dom0 image on the bare metal. This way you can
first make sure basic thermal logic in Linux works well in your environment.
There may have bug in thermal code, or it may be due to the config options.
anyway to first achieve a success with same dom0 image on bare metal would
narrow down the issue.

if it works, then you can check whether "dom0_vcpus_pin" is set and
make
sure you don''t limit the vcpu number.

Hope above experiments may give you some ideas. :-)

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel