Porting the intel_pstate driver to Xen

PATCH Superseded Wei Wang 3 participants 28 messages Apr 23, 2015 – Apr 29, 2015

lore

Share & tools

lore

Wei Wang

author

2015-04-23 13:34 UTC #0 lore raw

cover Porting the intel_pstate driver to Xen

Hi,

This patch series ports the intel_pstate driver from the Linux kernel to Xen. The intel_pstate driver is used to tune P states for SandyBridge+ processors. It can be disabled by adding "intel_pstate=disable" to the booting parameter list.

The intel_pstate.c file under xen/arch/x86/acpi/cpufreq/ contains all the logic for selecting the current P-state. It follows its implementation in the kernel. Instead of using the traditional cpufreq governors, intel_pstate implements its internal governor in the "setpolicy()". In order to better support future Intel CPUs (e.g. the HWP feature on Skylake+), intel_pstate changes to tune P-state based on percentage values.

The xenpm tool is also upgraded to support the intel_pstate driver. If intel_pstate is used, "get-cpufreq-para" displays percentage value based feedback. An example is shown below:
cpu id : 0
affected_cpus : 0
cpuinfo frequency : max [3700000] min [1200000] cur [1200000]
scaling_driver : intel_pstate
scaling_avail_gov : internal
current_governor : internal
num_pstates : 26
max_perf_pct : 100
min_perf_pct : 32
turbo_pct : 54
turbo mode : enabled

Wei Wang (9):
x86/acpi: add a common interface for matching the current cpu against
an array of x86_cpu_ids
x86/intel_pstate: add some calculation related support x86/cpu_hotplug: add the unregister_cpu_notifier function to support
CPU hotplug
x86/intel_pstate: add new policy fields and a new driver interface x86/intel_pstate: relocate the driver register/unregister function x86/intel_pstate: the main boby of the intel_pstate driver x86/intel_pstate: add a booting param to select the driver to load x86/intel_pstate: support the use of intel_pstate in pmstat.c x86/intel_pstate: enable xenpm to control the intel_pstate driver

 tools/libxc/include/xenctrl.h             |  20 +-
 tools/libxc/xc_pm.c                       |  26 +-
 tools/misc/xenpm.c                        | 101 +++-
 xen/arch/x86/acpi/cpufreq/Makefile        |   1 +
 xen/arch/x86/acpi/cpufreq/cpufreq.c       |   9 +-
 xen/arch/x86/acpi/cpufreq/intel_pstate.c  | 859 ++++++++++++++++++++++++++++++
 xen/arch/x86/cpu/common.c                 |  39 ++
 xen/arch/x86/cpu/mwait-idle.c             |  30 +-
 xen/common/cpu.c                          |   7 +
 xen/drivers/acpi/pmstat.c                 |  57 +-
 xen/drivers/cpufreq/cpufreq.c             |  27 +-
 xen/drivers/cpufreq/utility.c             |   5 +
 xen/include/acpi/cpufreq/cpufreq.h        |  44 +-
 xen/include/acpi/cpufreq/processor_perf.h |   3 +
 xen/include/asm-x86/cpufeature.h          |   1 +
 xen/include/asm-x86/div64.h               |  68 +++
 xen/include/asm-x86/msr-index.h           |   3 +
 xen/include/asm-x86/processor.h           |  10 +
 xen/include/public/sysctl.h               |  22 +-
 xen/include/xen/cpu.h                     |   1 +
 xen/include/xen/kernel.h                  |  30 ++
 21 files changed, 1261 insertions(+), 102 deletions(-)
 create mode 100644 xen/arch/x86/acpi/cpufreq/intel_pstate.c

Signature · 1 line

1.9.1

Jan Beulich

2015-04-23 14:09 UTC #1 lore raw

Quoted 6 lines

Quoted 1 line
Quoted 1 line · On 23.04.16 at 15:31, <[email protected]> wrote:
The intel_pstate.c file under xen/arch/x86/acpi/cpufreq/ contains all the logic for selecting the current P-state. It follows its implementation in the kernel. Instead of using the traditional cpufreq governors, intel_pstate implements its internal governor in the "setpolicy()".

And this internal governor behaves how? Like ondemand, powersave, peerformance, or yet something else? And how would its behavior be changed?

Jan

Wang, Wei W

author

2015-04-24 05:12 UTC #2 lore raw

Quoted 7 lines · Jan Beulich

Quoted 6 lines
Quoted 1 line
Quoted 1 line · On 23.04.16 at 15:31, <[email protected]> wrote:
The intel_pstate.c file under xen/arch/x86/acpi/cpufreq/ contains all the logic for selecting the current P-state. It follows its implementation in the kernel. Instead of using the traditional cpufreq governors, intel_pstate implements its internal governor in the "setpolicy()".

Quoted 5 lines

And this internal governor behaves how? Like ondemand, powersave, peerformance, or yet something else? And how would its behavior be changed?
Jan

Hi Jan,

In the kenel intel_pstate implementation, they have two internal governors: Powersave and Performance.
Powersave is similar to the old (cpufreq) ondemand governor. A timer function is periodically invoked to sample the CPU busy info (e.g. will get increased due to the running of a CPU-intensive workload). However, the final calculated target value is clamped into the [min_pct, max_pct] limit interval. The Performance governor is actually a special case of Powersave, when the min_pct= max_pct=100%. This is the same as the old performance governor.

Here in the ported version, the limit interval can be set via the new added interfaces in xenpm. I think we can make use of only the Powersave governor, and the Performance governor can actually be simply achieved by setting min_pct= max_pct=100%.

If all of you are agree, I will remove the Performance governor related code in the next version of patchset.

Best,
Wei

Jan Beulich

2015-04-24 07:26 UTC #3 lore raw

Quoted 13 lines

Quoted 1 line
Quoted 1 line · On 24.04.15 at 07:12, <[email protected]> wrote:
Quoted 10 lines · Jan Beulich
Quoted 6 lines
Quoted 1 line
Quoted 1 line · On 23.04.16 at 15:31, <[email protected]> wrote:
The intel_pstate.c file under xen/arch/x86/acpi/cpufreq/ contains all the logic for selecting the current P-state. It follows its implementation in the kernel. Instead of using the traditional cpufreq governors, intel_pstate implements its internal governor in the "setpolicy()".
And this internal governor behaves how? Like ondemand, powersave, peerformance, or yet something else? And how would its behavior be changed?

Quoted 9 lines

In the kenel intel_pstate implementation, they have two internal governors:
Powersave and Performance.
Powersave is similar to the old (cpufreq) ondemand governor. A timer function is periodically invoked to sample the CPU busy info (e.g. will get increased due to the running of a CPU-intensive workload). However, the final calculated target value is clamped into the [min_pct, max_pct] limit interval.
The Performance governor is actually a special case of Powersave, when the min_pct= max_pct=100%. This is the same as the old performance governor.

So a true powersave one would then be accomplished by setting min_pct = max_pct = <some value smaller than 100>%. Is there a limit on the valid percentages to be specified here?

Also, you calling "powersave" what supposedly is "ondemand" makes me nervous about it not immediately raising the CPU freq when load increases, yet imo that's a fundamental requirement for server kind loads where you don't want to run in "performance" mode. Can you clarify the behavior here?

Quoted 7 lines

Here in the ported version, the limit interval can be set via the new added interfaces in xenpm. I think we can make use of only the Powersave governor, and the Performance governor can actually be simply achieved by setting min_pct= max_pct=100%.
If all of you are agree, I will remove the Performance governor related code in the next version of patchset.

Yes, this certainly seems to make sense with the above.

Jan

Wang, Wei W

author

2015-04-24 08:32 UTC #4 lore raw

Quoted 22 lines · Jan Beulich

Quoted 13 lines
Quoted 1 line
Quoted 1 line · On 24.04.15 at 07:12, <[email protected]> wrote:
Quoted 10 lines · Jan Beulich
Quoted 6 lines
Quoted 1 line
Quoted 1 line · On 23.04.16 at 15:31, <[email protected]> wrote:
The intel_pstate.c file under xen/arch/x86/acpi/cpufreq/ contains all the logic for selecting the current P-state. It follows its implementation in the kernel. Instead of using the traditional cpufreq governors, intel_pstate implements its internal governor in the "setpolicy()".
And this internal governor behaves how? Like ondemand, powersave, peerformance, or yet something else? And how would its behavior be changed?
Quoted 9 lines
In the kenel intel_pstate implementation, they have two internal governors:
Powersave and Performance.
Powersave is similar to the old (cpufreq) ondemand governor. A timer function is periodically invoked to sample the CPU busy info (e.g. will get increased due to the running of a CPU-intensive workload). However, the final calculated target value is clamped into the [min_pct, max_pct] limit interval.
The Performance governor is actually a special case of Powersave, when the min_pct= max_pct=100%. This is the same as the old performance

Quoted 5 lines

governor.
So a true powersave one would then be accomplished by setting min_pct = max_pct = <some value smaller than 100>%. Is there a limit on the valid percentages to be specified here?

In the old driver, a powersave governor just sets the CPU to run with the lowest possible performance state. This one does not exist in the intel_pstate driver.
The intel_pstate driver changes the terminology by using "powersave" to refer to the previous "ondemand" case. This does make people feel confused. But we may think it this way: it only has two modes, the max performance mode and the ondemand mode. "ondemand" is the one who saves power (actually in a more reasonable way compared to the previous "powersave" which simply sets the CPU to run with the lowest performance state). Anyway, we can surely change the name if it sounds uncomfortable.

The valid pct value range is 0 to 100.

Quoted 6 lines

Also, you calling "powersave" what supposedly is "ondemand" makes me nervous about it not immediately raising the CPU freq when load increases, yet imo that's a fundamental requirement for server kind loads where you don't want to run in "performance" mode. Can you clarify the behavior here?

The timer fires very 10ms to update the CPU P-state according to the sampled workload info.

Best,
Wei

Quoted 12 lines

Quoted 8 lines
Here in the ported version, the limit interval can be set via the new added interfaces in xenpm. I think we can make use of only the Powersave governor, and the Performance governor can actually be simply achieved by setting min_pct= max_pct=100%.
If all of you are agree, I will remove the Performance governor related code in the next version of patchset.
Yes, this certainly seems to make sense with the above.
Jan

Jan Beulich

2015-04-24 09:10 UTC #5 lore raw

Quoted 31 lines

Quoted 1 line
Quoted 1 line · On 24.04.15 at 10:32, <[email protected]> wrote:
Quoted 22 lines · Jan Beulich
Quoted 13 lines
Quoted 1 line
Quoted 1 line · On 24.04.15 at 07:12, <[email protected]> wrote:
Quoted 10 lines · Jan Beulich
Quoted 6 lines
Quoted 1 line
Quoted 1 line · On 23.04.16 at 15:31, <[email protected]> wrote:
The intel_pstate.c file under xen/arch/x86/acpi/cpufreq/ contains all the logic for selecting the current P-state. It follows its implementation in the kernel. Instead of using the traditional cpufreq governors, intel_pstate implements its internal governor in the "setpolicy()".
And this internal governor behaves how? Like ondemand, powersave, peerformance, or yet something else? And how would its behavior be changed?
Quoted 9 lines
In the kenel intel_pstate implementation, they have two internal governors:
Powersave and Performance.
Powersave is similar to the old (cpufreq) ondemand governor. A timer function is periodically invoked to sample the CPU busy info (e.g. will get increased due to the running of a CPU-intensive workload). However, the final calculated target value is clamped into the [min_pct, max_pct] limit interval.
The Performance governor is actually a special case of Powersave, when the min_pct= max_pct=100%. This is the same as the old performance
Quoted 5 lines
governor.
So a true powersave one would then be accomplished by setting min_pct = max_pct = <some value smaller than 100>%. Is there a limit on the valid percentages to be specified here?

Quoted 10 lines

In the old driver, a powersave governor just sets the CPU to run with the lowest possible performance state. This one does not exist in the intel_pstate driver.
The intel_pstate driver changes the terminology by using "powersave" to refer to the previous "ondemand" case. This does make people feel confused. But we may think it this way: it only has two modes, the max performance mode and the ondemand mode. "ondemand" is the one who saves power (actually in a more reasonable way compared to the previous "powersave" which simply sets the CPU to run with the lowest performance state). Anyway, we can surely change the name if it sounds uncomfortable.

I think at the very least from a user interface perspective (e.g. the xenpm tool) the meaning of the old governor names should be retained as much as possible.

Quoted 1 line

The valid pct value range is 0 to 100.

So what does 0% mean then? I.e. (wrt "powersave") what does min_pct = max_pct = 0 result in?

Quoted 8 lines

Quoted 5 lines
Also, you calling "powersave" what supposedly is "ondemand" makes me nervous about it not immediately raising the CPU freq when load increases, yet imo that's a fundamental requirement for server kind loads where you don't want to run in "performance" mode. Can you clarify the behavior here?
The timer fires very 10ms to update the CPU P-state according to the sampled workload info.

But that doesn't tell what the action is that the timer initiates. I.e. under what conditions it would effect a frequency change.

Jan

Wang, Wei W

author

2015-04-24 09:46 UTC #6 lore raw

Quoted 44 lines · Jan Beulich

Quoted 11 lines
Quoted 1 line
Quoted 1 line · On 24.04.15 at 10:32, <[email protected]> wrote:
Quoted 9 lines · Jan Beulich
Quoted 9 lines
Quoted 1 line
Quoted 1 line · On 24.04.15 at 07:12, <[email protected]> wrote:
Quoted 7 lines · Jan Beulich
Quoted 6 lines
Quoted 1 line
Quoted 1 line · On 23.04.16 at 15:31, <[email protected]> wrote:
The intel_pstate.c file under xen/arch/x86/acpi/cpufreq/ contains all the logic for selecting the current P-state. It follows its implementation in the kernel. Instead of using the traditional cpufreq governors, intel_pstate implements its internal governor in the "setpolicy()".
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
And this internal governor behaves how? Like ondemand, powersave, peerformance, or yet something else? And how would its behavior be changed?
In the kenel intel_pstate implementation, they have two internal
governors:
Quoted 16 lines
Quoted 9 lines
Quoted 9 lines
Powersave and Performance.
Powersave is similar to the old (cpufreq) ondemand governor. A timer function is periodically invoked to sample the CPU busy info (e.g. will get increased due to the running of a CPU-intensive workload). However, the final calculated target value is clamped into the [min_pct, max_pct] limit interval.
The Performance governor is actually a special case of Powersave, when the min_pct= max_pct=100%. This is the same as the old performance
Quoted 5 lines
governor.
So a true powersave one would then be accomplished by setting min_pct = max_pct = <some value smaller than 100>%. Is there a limit on the valid percentages to be specified here?
Quoted 5 lines
In the old driver, a powersave governor just sets the CPU to run with the lowest possible performance state. This one does not exist in the intel_pstate driver.
The intel_pstate driver changes the terminology by using "powersave" to refer to the previous "ondemand" case. This does make people feel
confused.
Quoted 5 lines
But we may think it this way: it only has two modes, the max performance mode and the ondemand mode. "ondemand" is the one who saves power (actually in a more reasonable way compared to the previous "powersave" which simply sets the CPU to run with the lowest performance state). Anyway, we can surely change the name if it sounds

Quoted 5 lines

uncomfortable.
I think at the very least from a user interface perspective (e.g. the xenpm tool) the meaning of the old governor names should be retained as much as possible.

Ok. I am simply using the name "internal" for user tools. Please see the example below:

scaling_driver : intel_pstate
scaling_avail_gov : internal
current_governor : internal

Quoted 5 lines

Quoted 2 lines
The valid pct value range is 0 to 100.
So what does 0% mean then? I.e. (wrt "powersave") what does min_pct = max_pct = 0 result in?

Probably I misunderstood that question.
The CPU actually has its own valid frequency range. On my machine, for example, the minimal is 1.2GHZ (got from an MSR), which corresponds to 32%. Then the valid range is 32 to 100. Any input pct value less than 32 will be set to 32.

Quoted 7 lines

Quoted 7 lines
Quoted 6 lines
Also, you calling "powersave" what supposedly is "ondemand" makes me nervous about it not immediately raising the CPU freq when load increases, yet imo that's a fundamental requirement for server kind loads where you don't want to run in "performance" mode. Can you clarify the behavior here?

Quoted 5 lines

Quoted 2 lines
The timer fires very 10ms to update the CPU P-state according to the sampled workload info.
But that doesn't tell what the action is that the timer initiates. I.e. under what conditions it would effect a frequency change.

Each time when the timer is timer function is invoked, it gets the CPU utilization statistics using APERF and MPERF MSR registers. The current CPU utilization is compared to the previous one to generate a scale factor, which scales the frequency up or down.

Best,
Wei

Quoted 2 lines

Jan

Jan Beulich

2015-04-24 09:55 UTC #7 lore raw

Quoted 20 lines

Quoted 1 line
Quoted 1 line · On 24.04.15 at 11:46, <[email protected]> wrote:
Quoted 12 lines · Jan Beulich
Quoted 6 lines
Quoted 1 line
Quoted 1 line · On 24.04.15 at 10:32, <[email protected]> wrote:
In the old driver, a powersave governor just sets the CPU to run with the lowest possible performance state. This one does not exist in the intel_pstate driver.
The intel_pstate driver changes the terminology by using "powersave" to refer to the previous "ondemand" case. This does make people feel
confused.
Quoted 5 lines
But we may think it this way: it only has two modes, the max performance mode and the ondemand mode. "ondemand" is the one who saves power (actually in a more reasonable way compared to the previous "powersave" which simply sets the CPU to run with the lowest performance state). Anyway, we can surely change the name if it sounds
Quoted 5 lines
uncomfortable.
I think at the very least from a user interface perspective (e.g. the xenpm tool) the meaning of the old governor names should be retained as much as possible.

Quoted 6 lines

Ok. I am simply using the name "internal" for user tools. Please see the example below:
scaling_driver : intel_pstate
scaling_avail_gov : internal
current_governor : internal

But xenpm's set-scaling-governor command should still do something useful for the currently available governor options. And with that, showing "internal" in its output may also end up being confusing (at least I am already being confused).

Jan

Wang, Wei W

author

2015-04-24 10:07 UTC #8 lore raw

Quoted 27 lines · Jan Beulich

Quoted 9 lines
Quoted 1 line
Quoted 1 line · On 24.04.15 at 11:46, <[email protected]> wrote:
Quoted 7 lines · Jan Beulich
Quoted 7 lines
Quoted 1 line
Quoted 1 line · On 24.04.15 at 10:32, <[email protected]> wrote:
In the old driver, a powersave governor just sets the CPU to run with the lowest possible performance state. This one does not exist in the intel_pstate driver.
The intel_pstate driver changes the terminology by using "powersave" to refer to the previous "ondemand" case. This does make people feel
Quoted 3 lines
Quoted 3 lines
confused.
Quoted 2 lines
But we may think it this way: it only has two modes, the max performance mode and the ondemand mode. "ondemand" is the one
who
Quoted 14 lines
Quoted 10 lines
Quoted 4 lines
saves power (actually in a more reasonable way compared to the previous "powersave" which simply sets the CPU to run with the lowest performance state). Anyway, we can surely change the name if it sounds
uncomfortable.
I think at the very least from a user interface perspective (e.g. the xenpm
tool) the meaning of the old governor names should be retained as much as possible.
Ok. I am simply using the name "internal" for user tools. Please see the example below:

Quoted 8 lines

Quoted 3 lines
scaling_driver : intel_pstate
scaling_avail_gov : internal
current_governor : internal
But xenpm's set-scaling-governor command should still do something useful for the currently available governor options. And with that, showing "internal" in its output may also end up being confusing (at least I am already being confused).

The case is similar to that in the kernel. Xen has two pstate driver, but only one can be loaded. When the intel_pstate driver is used ("scaling_driver : intel_pstate "), xenpm's set-scaling-governor will not take effect, since the intel_pstate only implements its internal governor.

Quoted 2 lines

Jan

Jan Beulich

2015-04-24 10:19 UTC #9 lore raw

Quoted 38 lines

Quoted 1 line
Quoted 1 line · On 24.04.15 at 12:07, <[email protected]> wrote:
Quoted 27 lines · Jan Beulich
Quoted 9 lines
Quoted 1 line
Quoted 1 line · On 24.04.15 at 11:46, <[email protected]> wrote:
Quoted 7 lines · Jan Beulich
Quoted 7 lines
Quoted 1 line
Quoted 1 line · On 24.04.15 at 10:32, <[email protected]> wrote:
In the old driver, a powersave governor just sets the CPU to run with the lowest possible performance state. This one does not exist in the intel_pstate driver.
The intel_pstate driver changes the terminology by using "powersave" to refer to the previous "ondemand" case. This does make people feel
Quoted 3 lines
Quoted 3 lines
confused.
Quoted 2 lines
But we may think it this way: it only has two modes, the max performance mode and the ondemand mode. "ondemand" is the one
who
Quoted 14 lines
Quoted 10 lines
Quoted 4 lines
saves power (actually in a more reasonable way compared to the previous "powersave" which simply sets the CPU to run with the lowest performance state). Anyway, we can surely change the name if it sounds
uncomfortable.
I think at the very least from a user interface perspective (e.g. the xenpm
tool) the meaning of the old governor names should be retained as much as possible.
Ok. I am simply using the name "internal" for user tools. Please see the example below:
Quoted 8 lines
Quoted 3 lines
scaling_driver : intel_pstate
scaling_avail_gov : internal
current_governor : internal
But xenpm's set-scaling-governor command should still do something useful for the currently available governor options. And with that, showing "internal" in its output may also end up being confusing (at least I am already being confused).

Quoted 4 lines

The case is similar to that in the kernel. Xen has two pstate driver, but only one can be loaded. When the intel_pstate driver is used ("scaling_driver
: intel_pstate "), xenpm's set-scaling-governor will not take effect, since
the intel_pstate only implements its internal governor.

But that's precisely what I'm asking to be changed: Even if internally is uses its own governor, the user interface of the tool should still be usable to achieve similar effects.

Jan

Wang, Wei W

author

2015-04-24 11:53 UTC #10 lore raw

On 24/04/2015 18:20, Jan Beulich wrote

Quoted 24 lines

Quoted 17 lines
Quoted 1 line
Quoted 1 line · On 24.04.15 at 12:07, <[email protected]> wrote:
Quoted 15 lines · Jan Beulich
Quoted 14 lines
Quoted 1 line
Quoted 1 line · On 24.04.15 at 11:46, <[email protected]> wrote:
Quoted 5 lines · Jan Beulich
Quoted 1 line
Quoted 1 line
Quoted 1 line · On 24.04.15 at 10:32, <[email protected]> wrote:
I think at the very least from a user interface perspective (e.g. the xenpm
tool) the meaning of the old governor names should be retained as much as possible.
Ok. I am simply using the name "internal" for user tools. Please see the example below:
scaling_driver : intel_pstate
scaling_avail_gov : internal
current_governor : internal
Quoted 7 lines
Quoted 4 lines
But xenpm's set-scaling-governor command should still do something useful for the currently available governor options. And with that, showing "internal" in its output may also end up being confusing (at least I am already being confused).
The case is similar to that in the kernel. Xen has two pstate driver, but only one can be loaded. When the intel_pstate driver is used

Quoted 7 lines

("scaling_driver
Quoted 2 lines
: intel_pstate "), xenpm's set-scaling-governor will not take effect, since
the intel_pstate only implements its internal governor.
But that's precisely what I'm asking to be changed: Even if internally is uses its own governor, the user interface of the tool should still be usable to achieve similar effects.

Yes, we should change that if we remain two governors in the intel_pstate driver.
But as we discussed before, the internal Performance governor seems redundant and can be removed. In that case, there is no other option of governors that be selected by the user via set-scaling-governor.

Best,
Wei

Jan Beulich

2015-04-24 12:56 UTC #11 lore raw

Quoted 33 lines

Quoted 1 line
Quoted 1 line · On 24.04.15 at 13:53, <[email protected]> wrote:
On 24/04/2015 18:20, Jan Beulich wrote
Quoted 17 lines
Quoted 17 lines
Quoted 1 line
Quoted 1 line · On 24.04.15 at 12:07, <[email protected]> wrote:
Quoted 15 lines · Jan Beulich
Quoted 14 lines
Quoted 1 line
Quoted 1 line · On 24.04.15 at 11:46, <[email protected]> wrote:
Quoted 5 lines · Jan Beulich
Quoted 1 line
Quoted 1 line
Quoted 1 line · On 24.04.15 at 10:32, <[email protected]> wrote:
I think at the very least from a user interface perspective (e.g. the xenpm
tool) the meaning of the old governor names should be retained as much as possible.
Ok. I am simply using the name "internal" for user tools. Please see the example below:
scaling_driver : intel_pstate
scaling_avail_gov : internal
current_governor : internal
Quoted 9 lines
Quoted 7 lines
Quoted 4 lines
But xenpm's set-scaling-governor command should still do something useful for the currently available governor options. And with that, showing "internal" in its output may also end up being confusing (at least I am already being confused).
The case is similar to that in the kernel. Xen has two pstate driver, but only one can be loaded. When the intel_pstate driver is used
("scaling_driver
Quoted 1 line
: intel_pstate "), xenpm's set-scaling-governor will not take effect,
since
Quoted 3 lines
Quoted 1 line
the intel_pstate only implements its internal governor.
But that's precisely what I'm asking to be changed: Even if internally is
uses

Quoted 8 lines

Quoted 2 lines
its own governor, the user interface of the tool should still be usable to achieve similar effects.
Yes, we should change that if we remain two governors in the intel_pstate driver.
But as we discussed before, the internal Performance governor seems redundant and can be removed. In that case, there is no other option of governors that be selected by the user via set-scaling-governor.

I'm not sure how else to express what I want (no matter how many internal governors the intel_pstate driver has).

xenpm set-scaling-governor powersave
xenpm set-scaling-governor ondemand
xenpm set-scaling-governor performance

each should switch the system into a respective state, no matter whether internally to the driver this means a change of governors or just a modification to {min,max}_pct.

And obtaining the current state after any of the above should show the same governor in use that was set (and not "internal"), again no matter how this is being achieved internally to the driver.

Jan

Wang, Wei W

author

2015-04-24 14:56 UTC #12 lore raw

On 24/04/2015 20:57, Jan Beulich wrote

Quoted 51 lines

Quoted 35 lines
Quoted 1 line
Quoted 1 line · On 24.04.15 at 13:53, <[email protected]> wrote:
On 24/04/2015 18:20, Jan Beulich wrote
Quoted 22 lines
Quoted 22 lines
Quoted 1 line
Quoted 1 line · On 24.04.15 at 12:07, <[email protected]> wrote:
Quoted 19 lines · Jan Beulich
Quoted 8 lines
Quoted 1 line
Quoted 1 line · On 24.04.15 at 11:46, <[email protected]> wrote:
Quoted 5 lines · Jan Beulich
Quoted 1 line
Quoted 1 line
Quoted 1 line · On 24.04.15 at 10:32, <[email protected]> wrote:
I think at the very least from a user interface perspective (e.g. the xenpm
tool) the meaning of the old governor names should be retained as much as possible.
Quoted 6 lines
Ok. I am simply using the name "internal" for user tools. Please see the example below:
scaling_driver : intel_pstate
scaling_avail_gov : internal
current_governor : internal
But xenpm's set-scaling-governor command should still do something useful for the currently available governor options. And with that, showing "internal" in its output may also end up being confusing (at least I am already being confused).
Quoted 5 lines
Quoted 3 lines
The case is similar to that in the kernel. Xen has two pstate driver, but only one can be loaded. When the intel_pstate driver is used
("scaling_driver
Quoted 1 line
: intel_pstate "), xenpm's set-scaling-governor will not take effect,
since
Quoted 4 lines
Quoted 1 line
the intel_pstate only implements its internal governor.
But that's precisely what I'm asking to be changed: Even if internally is
uses
Quoted 8 lines
Quoted 2 lines
its own governor, the user interface of the tool should still be usable to achieve similar effects.
Yes, we should change that if we remain two governors in the intel_pstate driver.
But as we discussed before, the internal Performance governor seems redundant and can be removed. In that case, there is no other option of governors that be selected by the user via set-scaling-governor.
I'm not sure how else to express what I want (no matter how many internal governors the intel_pstate driver has).
xenpm set-scaling-governor powersave
xenpm set-scaling-governor ondemand
xenpm set-scaling-governor performance

Quoted 7 lines

each should switch the system into a respective state, no matter whether internally to the driver this means a change of governors or just a modification to {min,max}_pct.
And obtaining the current state after any of the above should show the same governor in use that was set (and not "internal"), again no matter how this is being achieved internally to the driver.

Thanks Jan, that's clear. But this will have another issue. For example, we set-scaling-governor to "ondemand", then we adjust min_pct=max_pct = 60%. The timer function may generate results like 35%, 55%, 45%..., but the CPU just keeps running with 60%. Then, this is not "ondemand" at all (I think this should be another reason why the intel_pstate driver does not call its governor "ondemand").

The intel_pstate driver in the kernel has already got rid of the old governor convention. They let the user get what they want through simply adjusting the {min,max}_pct (the {min,max}_pct actually limits how the performance is selected).

I think we can follow the kernel implementation regarding this point, what do you think?

Best,
Wei

Jan Beulich

2015-04-24 15:03 UTC #13 lore raw

Quoted 13 lines

Quoted 1 line
Quoted 1 line · On 24.04.15 at 16:56, <[email protected]> wrote:
On 24/04/2015 20:57, Jan Beulich wrote
Quoted 11 lines
I'm not sure how else to express what I want (no matter how many internal governors the intel_pstate driver has).
xenpm set-scaling-governor powersave
xenpm set-scaling-governor ondemand
xenpm set-scaling-governor performance
each should switch the system into a respective state, no matter whether internally to the driver this means a change of governors or just a modification to {min,max}_pct.

Quoted 8 lines

Quoted 3 lines
And obtaining the current state after any of the above should show the same governor in use that was set (and not "internal"), again no matter how this is being achieved internally to the driver.
Thanks Jan, that's clear. But this will have another issue. For example, we set-scaling-governor to "ondemand", then we adjust min_pct=max_pct = 60%. The timer function may generate results like 35%, 55%, 45%..., but the CPU just keeps running with 60%.

So I must be misunderstanding something then: How can the driver do anything at all when told to run the system at 60%?

Quoted 8 lines

Then, this is not "ondemand" at all (I think this
should be another reason why the intel_pstate driver does not call its governor "ondemand").
The intel_pstate driver in the kernel has already got rid of the old governor convention. They let the user get what they want through simply adjusting the {min,max}_pct (the {min,max}_pct actually limits how the performance is selected).

Adjusting the values individually to me very much looks like the userspace governor.

Quoted 2 lines

I think we can follow the kernel implementation regarding this point, what do you think?

Not sure - I'm not always convinced that what Linux does is the one and only and best way.

Jan

Wang, Wei W

author

2015-04-24 15:42 UTC #14 lore raw

On 24/04/2015 23:04, Jan Beulich wrote

Quoted 17 lines

Quoted 17 lines
Quoted 1 line
Quoted 1 line · On 24.04.15 at 16:56, <[email protected]> wrote:
On 24/04/2015 20:57, Jan Beulich wrote
Quoted 14 lines
I'm not sure how else to express what I want (no matter how many internal governors the intel_pstate driver has).
xenpm set-scaling-governor powersave
xenpm set-scaling-governor ondemand
xenpm set-scaling-governor performance
each should switch the system into a respective state, no matter whether internally to the driver this means a change of governors or just a modification to {min,max}_pct.
And obtaining the current state after any of the above should show the same governor in use that was set (and not "internal"), again no matter how this is being achieved internally to the driver.

Quoted 7 lines

Quoted 4 lines
Thanks Jan, that's clear. But this will have another issue. For example, we set-scaling-governor to "ondemand", then we adjust min_pct=max_pct = 60%. The timer function may generate results like 35%, 55%, 45%..., but the CPU just keeps running with 60%.
So I must be misunderstanding something then: How can the driver do anything at all when told to run the system at 60%?

The {min,max}_pct is a limit. The timer function figures out a proper value based on the sampled statistics, then this value is clamped into [min_pct, max_pct]. When we have [60%, 60%], whatever the value from the timer function is, it will be finally adjusted to 60%, and set to the perf_ctl register.

Quoted 11 lines

Quoted 8 lines
Then, this is not "ondemand" at all (I think this should be another reason why the intel_pstate driver does not call its governor "ondemand").
The intel_pstate driver in the kernel has already got rid of the old governor convention. They let the user get what they want through simply adjusting the {min,max}_pct (the {min,max}_pct actually limits how the performance is selected).
Adjusting the values individually to me very much looks like the userspace governor.

Yeah, that example was like "userspace". Please take a look at this example: [min_pct=60%, max_pct=80%], the timer generates 45%, 55%, 65%, 70%, 75%, 90%, then the final target values will not be constant. The ones (65%, 70%, 75%) falling into the limit interval behaves like "ondemand", others are not.

Quoted 6 lines

Quoted 3 lines
I think we can follow the kernel implementation regarding this point, what do you think?
Not sure - I'm not always convinced that what Linux does is the one and only and best way.

Understand it. But I think that usage is good, in terms of supporting future intel processors (e.g. the hardware controlled P-states on Skylake+). The {min,max}_pct needs to be exposed to users to set the limits.

Best,
Wei

Jan Beulich

2015-04-24 15:53 UTC #15 lore raw

Quoted 24 lines

Quoted 1 line
Quoted 1 line · On 24.04.15 at 17:42, <[email protected]> wrote:
On 24/04/2015 23:04, Jan Beulich wrote
Quoted 22 lines
Quoted 21 lines
Quoted 1 line
Quoted 1 line · On 24.04.15 at 16:56, <[email protected]> wrote:
On 24/04/2015 20:57, Jan Beulich wrote
Quoted 7 lines
I'm not sure how else to express what I want (no matter how many internal governors the intel_pstate driver has).
xenpm set-scaling-governor powersave
xenpm set-scaling-governor ondemand
xenpm set-scaling-governor performance
Quoted 7 lines
each should switch the system into a respective state, no matter whether internally to the driver this means a change of governors or just a modification to {min,max}_pct.
And obtaining the current state after any of the above should show the same governor in use that was set (and not "internal"), again no matter how this is being achieved internally to the driver.
Thanks Jan, that's clear. But this will have another issue. For example, we set-scaling-governor to "ondemand", then we adjust min_pct=max_pct = 60%. The timer function may generate results like 35%, 55%, 45%..., but the CPU just keeps running with 60%.

Quoted 4 lines

Quoted 2 lines
So I must be misunderstanding something then: How can the driver do anything at all when told to run the system at 60%?
The {min,max}_pct is a limit.

That's clear. The question is whether these are hardware imposed limits or set by the user. In the latter case ...

Quoted 9 lines

Quoted 9 lines
Quoted 8 lines
Then, this is not "ondemand" at all (I think this should be another reason why the intel_pstate driver does not call its governor "ondemand").
The intel_pstate driver in the kernel has already got rid of the old governor convention. They let the user get what they want through simply adjusting the {min,max}_pct (the {min,max}_pct actually limits how the performance is selected).

Quoted 6 lines

Quoted 2 lines
Adjusting the values individually to me very much looks like the userspace governor.
Yeah, that example was like "userspace". Please take a look at this example:
[min_pct=60%, max_pct=80%], the timer generates 45%, 55%, 65%, 70%, 75%, 90%, then the final target values will not be constant.

(the 45%, 55%, and 90% here shouldn't happen in any case)

Quoted 2 lines

The ones (65%, 70%, 75%)
falling into the limit interval behaves like "ondemand", others are not.

... restricting to these would be the job of the driver, and
- ondemand would be 0...100
- powersave would be 0
- performance would be 100
Everything else would be userspace.

Jan

Wang, Wei W

author

2015-04-24 16:17 UTC #16 lore raw

On 24/04/2015 23:54, Jan Beulich wrote

Quoted 23 lines

Quoted 23 lines
Quoted 1 line
Quoted 1 line · On 24.04.15 at 17:42, <[email protected]> wrote:
On 24/04/2015 23:04, Jan Beulich wrote
Quoted 21 lines
Quoted 20 lines
Quoted 1 line
Quoted 1 line · On 24.04.15 at 16:56, <[email protected]> wrote:
On 24/04/2015 20:57, Jan Beulich wrote
Quoted 6 lines
I'm not sure how else to express what I want (no matter how many internal governors the intel_pstate driver has).
xenpm set-scaling-governor powersave xenpm set-scaling-governor ondemand xenpm set-scaling-governor performance
Quoted 7 lines
each should switch the system into a respective state, no matter whether internally to the driver this means a change of governors or just a modification to {min,max}_pct.
And obtaining the current state after any of the above should show the same governor in use that was set (and not "internal"), again no matter how this is being achieved internally to the driver.
Thanks Jan, that's clear. But this will have another issue. For example, we set-scaling-governor to "ondemand", then we adjust min_pct=max_pct = 60%. The timer function may generate results like 35%, 55%, 45%..., but the CPU just keeps running with 60%.

Quoted 7 lines

Quoted 4 lines
Quoted 2 lines
So I must be misunderstanding something then: How can the driver do anything at all when told to run the system at 60%?
The {min,max}_pct is a limit.
That's clear. The question is whether these are hardware imposed limits or set by the user. In the latter case ...

The hardware CPU has its own minimal performance limit, let's call it hw_min_pct. For example, on my machine, the hw_min_cpt=32% (corresponds to 1.2GHZ, which is the minimal frequency). The [min,max]_pct in our discussion is set by the user via xenpm. If min_pct is set to a value less than 32%, than it will be adjusted to hw_min_cpt.

Quoted 9 lines

Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
Then, this is not "ondemand" at all (I think this should be another reason why the intel_pstate driver does not call its governor "ondemand").
The intel_pstate driver in the kernel has already got rid of the old governor convention. They let the user get what they want through simply adjusting the {min,max}_pct (the {min,max}_pct actually limits how the performance is selected).

Quoted 8 lines

Quoted 6 lines
Quoted 2 lines
Adjusting the values individually to me very much looks like the userspace governor.
Yeah, that example was like "userspace". Please take a look at this example:
[min_pct=60%, max_pct=80%], the timer generates 45%, 55%, 65%, 70%, 75%, 90%, then the final target values will not be constant.
(the 45%, 55%, and 90% here shouldn't happen in any case)

Yes. The final values will be 60%, 60%, 65%, 70%, 75%, 80%. This is neither a "userspace" governor nor a "ondemand" governor.

Quoted 8 lines

Quoted 2 lines
The ones (65%, 70%, 75%)
falling into the limit interval behaves like "ondemand", others are not.
... restricting to these would be the job of the driver, and
- ondemand would be 0...100
- powersave would be 0
- performance would be 100
Everything else would be userspace.

Please see the example above, the internal governor in the new driver is different from these conventional governors.

Best,
Wei

Konrad Rzeszutek Wilk

2015-04-24 16:14 UTC #17 lore raw

In reply to Wang, Wei W

Quoted 43 lines · Wei W

On 24/04/2015 23:04, Jan Beulich wrote
Quoted 17 lines
Quoted 17 lines
Quoted 1 line
Quoted 1 line · On 24.04.15 at 16:56, <[email protected]> wrote:
On 24/04/2015 20:57, Jan Beulich wrote
Quoted 14 lines
I'm not sure how else to express what I want (no matter how many internal governors the intel_pstate driver has).
xenpm set-scaling-governor powersave
xenpm set-scaling-governor ondemand
xenpm set-scaling-governor performance
each should switch the system into a respective state, no matter whether internally to the driver this means a change of governors or just a modification to {min,max}_pct.
And obtaining the current state after any of the above should show the same governor in use that was set (and not "internal"), again no matter how this is being achieved internally to the driver.
Quoted 7 lines
Quoted 4 lines
Thanks Jan, that's clear. But this will have another issue. For example, we set-scaling-governor to "ondemand", then we adjust min_pct=max_pct = 60%. The timer function may generate results like 35%, 55%, 45%..., but the CPU just keeps running with 60%.
So I must be misunderstanding something then: How can the driver do anything at all when told to run the system at 60%?
The {min,max}_pct is a limit. The timer function figures out a proper value based on the sampled statistics, then this value is clamped into [min_pct, max_pct]. When we have [60%, 60%], whatever the value from the timer function is, it will be finally adjusted to 60%, and set to the perf_ctl register.
Quoted 11 lines
Quoted 8 lines
Then, this is not "ondemand" at all (I think this should be another reason why the intel_pstate driver does not call its governor "ondemand").
The intel_pstate driver in the kernel has already got rid of the old governor convention. They let the user get what they want through simply adjusting the {min,max}_pct (the {min,max}_pct actually limits how the performance is selected).
Adjusting the values individually to me very much looks like the userspace governor.
Yeah, that example was like "userspace". Please take a look at this example: [min_pct=60%, max_pct=80%], the timer generates 45%, 55%, 65%, 70%, 75%, 90%, then the final target values will not be constant. The ones (65%, 70%, 75%) falling into the limit interval behaves like "ondemand", others are not.
Quoted 1 line

Quoted 7 lines

Quoted 5 lines
Quoted 2 lines
I think we can follow the kernel implementation regarding this point, what do you think?
Not sure - I'm not always convinced that what Linux does is the one and only and best way.
Understand it. But I think that usage is good, in terms of supporting future intel processors (e.g. the hardware controlled P-states on Skylake+). The {min,max}_pct needs to be exposed to users to set the limits.

How will this affect AMD processors which can use the cpufreq? Would the ondemand feature go away?

Quoted 9 lines

Best,
Wei
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

Wang, Wei W

author

2015-04-24 16:32 UTC #18 lore raw

On 25/04/2015 00:15, Konrad Rzeszutek Wilk wrote

Quoted 56 lines · Wei W

Quoted 22 lines
On 24/04/2015 23:04, Jan Beulich wrote
Quoted 21 lines
Quoted 20 lines
Quoted 1 line
Quoted 1 line · On 24.04.15 at 16:56, <[email protected]> wrote:
On 24/04/2015 20:57, Jan Beulich wrote
Quoted 6 lines
I'm not sure how else to express what I want (no matter how many internal governors the intel_pstate driver has).
xenpm set-scaling-governor powersave xenpm set-scaling-governor ondemand xenpm set-scaling-governor performance
Quoted 7 lines
each should switch the system into a respective state, no matter whether internally to the driver this means a change of governors or just a modification to {min,max}_pct.
And obtaining the current state after any of the above should show the same governor in use that was set (and not "internal"), again no matter how this is being achieved internally to the driver.
Thanks Jan, that's clear. But this will have another issue. For example, we set-scaling-governor to "ondemand", then we adjust min_pct=max_pct = 60%. The timer function may generate results like 35%, 55%, 45%..., but the CPU just keeps running with 60%.
Quoted 4 lines
Quoted 2 lines
So I must be misunderstanding something then: How can the driver do anything at all when told to run the system at 60%?
The {min,max}_pct is a limit. The timer function figures out a proper value
based on the sampled statistics, then this value is clamped into [min_pct, max_pct]. When we have [60%, 60%], whatever the value from the timer function is, it will be finally adjusted to 60%, and set to the perf_ctl register.
Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
Then, this is not "ondemand" at all (I think this should be another reason why the intel_pstate driver does not call its governor "ondemand").
The intel_pstate driver in the kernel has already got rid of the old governor convention. They let the user get what they want through simply adjusting the {min,max}_pct (the {min,max}_pct actually limits how the performance is selected).
Quoted 4 lines
Quoted 2 lines
Adjusting the values individually to me very much looks like the userspace governor.
Yeah, that example was like "userspace". Please take a look at this example:
[min_pct=60%, max_pct=80%], the timer generates 45%, 55%, 65%, 70%, 75%, 90%, then the final target values will not be constant. The ones (65%, 70%, 75%) falling into the limit interval behaves like "ondemand", others are not.
Quoted 8 lines
Quoted 7 lines
Quoted 4 lines
I think we can follow the kernel implementation regarding this point, what do you think?
Not sure - I'm not always convinced that what Linux does is the one and only and best way.

Quoted 6 lines

Quoted 1 line
Understand it. But I think that usage is good, in terms of supporting future
intel processors (e.g. the hardware controlled P-states on Skylake+). The {min,max}_pct needs to be exposed to users to set the limits.
How will this affect AMD processors which can use the cpufreq? Would the ondemand feature go away?

No, this won't affect them. When the "intel_pstate=disable" is added to the booting parameter list, the old cpufreq driver will be used, and everything, including xenpm, will work in the old style.

The new driver, intel_pstate, actually works in a mode similar to the ondemand (probably can be called enhanced ondemand - the user can set a limit range for the "ondemand").

Best,
Wei

Jan Beulich

2015-04-28 13:13 UTC #19 lore raw

Quoted 8 lines

Quoted 1 line
Quoted 1 line
"Wang, Wei W" <[email protected]> 04/24/15 6:32 PM >>>
On 25/04/2015 00:15, Konrad Rzeszutek Wilk wrote
Quoted 2 lines
How will this affect AMD processors which can use the cpufreq? Would the ondemand feature go away?
No, this won't affect them. When the "intel_pstate=disable" is added to the booting parameter list, the old cpufreq driver will be used, and everything, including xenpm, will work in the old style.

That wouldn't suffice. On AMD (and older Intel) platforms it shouldn't be necessary to specifiy the option to retain current functionality.

Jan

Wang, Wei W

author

2015-04-28 13:24 UTC #20 lore raw

On 28/04/2015 21:14, Jan Beulich wrote

Quoted 10 lines

Quoted 7 lines
On 25/04/2015 00:15, Konrad Rzeszutek Wilk wrote
Quoted 2 lines
How will this affect AMD processors which can use the cpufreq? Would the ondemand feature go away?
No, this won't affect them. When the "intel_pstate=disable" is added to the booting parameter list, the old cpufreq driver will be used, and everything, including xenpm, will work in the old style.
That wouldn't suffice. On AMD (and older Intel) platforms it shouldn't be necessary to specifiy the option to retain current functionality.

No problem, I will change it with "intel_pstate=enable" to enable the intel_pstate driver. Then others will not be bothered.

Best,
Wei

Jan Beulich

2015-04-28 13:28 UTC #21 lore raw

Quoted 10 lines

Quoted 1 line
Quoted 1 line
"Wang, Wei W" <[email protected]> 04/28/15 3:24 PM >>>
On 28/04/2015 21:14, Jan Beulich wrote
Quoted 8 lines
Quoted 7 lines
On 25/04/2015 00:15, Konrad Rzeszutek Wilk wrote
Quoted 2 lines
How will this affect AMD processors which can use the cpufreq? Would the ondemand feature go away?
No, this won't affect them. When the "intel_pstate=disable" is added to the booting parameter list, the old cpufreq driver will be used, and everything, including xenpm, will work in the old style.

Quoted 5 lines

Quoted 2 lines
That wouldn't suffice. On AMD (and older Intel) platforms it shouldn't be necessary to specifiy the option to retain current functionality.
No problem, I will change it with "intel_pstate=enable" to enable the intel_pstate driver. Then others will not be bothered.

For new code this might be a good idea anyway, but that wasn't my point. Instead, even with "intel_pstate=enable" on an old Intel (or AMD) system (regardless of doing so being pointless) there shouldn't be any behavioral difference.

Jan

Wang, Wei W

author

2015-04-28 13:40 UTC #22 lore raw

On 28/04/2015 21:29, Jan Beulich wrote

Quoted 14 lines

Quoted 12 lines
Quoted 1 line
Quoted 1 line
"Wang, Wei W" <[email protected]> 04/28/15 3:24 PM >>>
On 28/04/2015 21:14, Jan Beulich wrote
Quoted 10 lines
Quoted 7 lines
On 25/04/2015 00:15, Konrad Rzeszutek Wilk wrote
Quoted 2 lines
How will this affect AMD processors which can use the cpufreq? Would the ondemand feature go away?
No, this won't affect them. When the "intel_pstate=disable" is added to the booting parameter list, the old cpufreq driver will be used, and everything, including xenpm, will work in the old style.
That wouldn't suffice. On AMD (and older Intel) platforms it shouldn't be necessary to specifiy the option to retain current
functionality.
Quoted 1 line

Quoted 7 lines

Quoted 2 lines
No problem, I will change it with "intel_pstate=enable" to enable the intel_pstate driver. Then others will not be bothered.
For new code this might be a good idea anyway, but that wasn't my point. Instead, even with "intel_pstate=enable" on an old Intel (or AMD) system (regardless of doing so being pointless) there shouldn't be any behavioral difference.

Hi Jan,

Please have a check my conclusion of the changes.
By the way, just a reminder for people who were not involved in the discussion before: the changed things in this patchset are intel_pstate specific. The changes in xenpm only take effect when the intel_pstate driver is loaded. If "intel_pstate=enable" is not added to the booting parameter list, all the things will work in their old style as before.

NO.1
The intel_pstate driver can be controlled via two ways:
1) min_perf_pct and max_perf_pct
The user directly adjusts min_perf_pct and max_perf_pct to get what they want. For example, if min_perf_pct=max_perf_pct=60%, then the user is asking for something similar to a userspace governor with setting the requested performance=60%.
2) set-scaling-governor
This one is functionally redundant, since 1) can achieve all the governor functions. It is remained to give people time to get familiar with method 1).
Users can choose from the four governors: Powersave, Ondemand, Powersave, Performance.
The driver will achieve the functionality of the selected governor via adjusting the min_perf_pct and max_perf_pct itself.

NO.2
The xenpm "get-cpufreq-para" will display the following things:
cpu id : 0
affected_cpus : 0
cpuinfo frequency : max [3700000] min [1200000] cur [1200000]
scaling_driver : intel_pstate
scaling_avail_gov : Performance Powersave Ondemand Userspace
current_governor : Ondemand
max_perf_pct : 100
min_perf_pct : 32
turbo_pct : 54
turbo mode : enabled

The governor info (scaling_avail_gov and current_governor) is still remained here, because there is no "get-scaling-governor" interface in xenpm. In the future when we remove "set-scaling-governor", we can remove the two lines. Also, the pstate_num line, which shows the total number of the CPU's P-states, is removed.

NO.3
Change "intel_pstate=disable" with "intel_pstate=enable" to specifically request the loading of the intel_pstate driver.

NO.4
We will move the declarations under xen/include/acpi to an x86-specific header.

Best,
Wei

Jan Beulich

2015-04-28 23:06 UTC #23 lore raw

Quoted 2 lines

Quoted 1 line
Quoted 1 line
"Wang, Wei W" <[email protected]> 04/28/15 3:41 PM >>>
Please have a check my conclusion of the changes.

These look all correct, with ...

Quoted 8 lines

NO.2
The xenpm "get-cpufreq-para" will display the following things:
cpu id : 0
affected_cpus : 0
cpuinfo frequency : max [3700000] min [1200000] cur [1200000]
scaling_driver : intel_pstate
scaling_avail_gov : Performance Powersave Ondemand Userspace
current_governor : Ondemand

... the last two lines being kind of pointless, and hence perhaps omitting them in the intel_pstate case would be better. Bus as said while talking to you, I'm not insisting on that (and also couldn't really, not being the maintainer of that code).

Jan

Wang, Wei W

author

2015-04-29 00:20 UTC #24 lore raw

On 29/04/2015 08:11, Jan Beulich wrote

Quoted 14 lines

Quoted 2 lines
Quoted 1 line
Quoted 1 line
"Wang, Wei W" <[email protected]> 04/28/15 3:41 PM >>>
Please have a check my conclusion of the changes.
These look all correct, with ...
Quoted 8 lines
NO.2
The xenpm "get-cpufreq-para" will display the following things:
cpu id : 0
affected_cpus : 0
cpuinfo frequency : max [3700000] min [1200000] cur [1200000]
scaling_driver : intel_pstate
scaling_avail_gov : Performance Powersave Ondemand Userspace
current_governor : Ondemand

Quoted 4 lines

... the last two lines being kind of pointless, and hence perhaps omitting them in the intel_pstate case would be better. Bus as said while talking to you, I'm not insisting on that (and also couldn't really, not being the maintainer of that code).

Now, we still keep the "set-scaling-governor" option to let the user tune performance via selecting a governor, so I think we should let them know which governor mode the CPU is on. In our talk, we assumed there is a "get-scaling-governor" option to achieve so, but that option doesn't exist. So I think it's better to keep this piece of info in the "get-cpufreq-para" here.

Best,
Wei

Wang, Wei W

author

2015-04-28 14:38 UTC #25 lore raw

In reply to Jan Beulich

On 28/04/2015 21:29, Jan Beulich wrote

Quoted 14 lines

Quoted 12 lines
Quoted 1 line
Quoted 1 line
"Wang, Wei W" <[email protected]> 04/28/15 3:24 PM >>>
On 28/04/2015 21:14, Jan Beulich wrote
Quoted 10 lines
Quoted 7 lines
On 25/04/2015 00:15, Konrad Rzeszutek Wilk wrote
Quoted 2 lines
How will this affect AMD processors which can use the cpufreq? Would the ondemand feature go away?
No, this won't affect them. When the "intel_pstate=disable" is added to the booting parameter list, the old cpufreq driver will be used, and everything, including xenpm, will work in the old style.
That wouldn't suffice. On AMD (and older Intel) platforms it shouldn't be necessary to specifiy the option to retain current
functionality.
Quoted 1 line

Quoted 7 lines

Quoted 2 lines
No problem, I will change it with "intel_pstate=enable" to enable the intel_pstate driver. Then others will not be bothered.
For new code this might be a good idea anyway, but that wasn't my point. Instead, even with "intel_pstate=enable" on an old Intel (or AMD) system (regardless of doing so being pointless) there shouldn't be any behavioral difference.

Without " intel_pstate=enable" added, the old acpi-cpufreq driver will be loaded, so shouldn't be a problem.

Best,
Wei

Jan Beulich

2015-04-28 23:09 UTC #26 lore raw

Quoted 19 lines

Quoted 1 line
Quoted 1 line
"Wang, Wei W" <[email protected]> 04/28/15 4:38 PM >>>
On 28/04/2015 21:29, Jan Beulich wrote
Quoted 17 lines
Quoted 12 lines
Quoted 1 line
Quoted 1 line
"Wang, Wei W" <[email protected]> 04/28/15 3:24 PM >>>
On 28/04/2015 21:14, Jan Beulich wrote
Quoted 10 lines
Quoted 7 lines
On 25/04/2015 00:15, Konrad Rzeszutek Wilk wrote
Quoted 2 lines
How will this affect AMD processors which can use the cpufreq? Would the ondemand feature go away?
No, this won't affect them. When the "intel_pstate=disable" is added to the booting parameter list, the old cpufreq driver will be used, and everything, including xenpm, will work in the old style.
That wouldn't suffice. On AMD (and older Intel) platforms it shouldn't be necessary to specifiy the option to retain current
functionality.
Quoted 3 lines
No problem, I will change it with "intel_pstate=enable" to enable the intel_pstate driver. Then others will not be bothered.

Quoted 6 lines

Quoted 4 lines
For new code this might be a good idea anyway, but that wasn't my point. Instead, even with "intel_pstate=enable" on an old Intel (or AMD) system (regardless of doing so being pointless) there shouldn't be any behavioral difference.
Without " intel_pstate=enable" added, the old acpi-cpufreq driver will be loaded, so shouldn't be a problem.

While I would have thought this to be an obvious thing anyway, it looks like we still don't understand each other. As much as it is (supposed to be) natural that in the absence of that command line option things behave as before, it should also be so if the option _was_ given but the driver didn't find suitable hardware.

Jan

Wang, Wei W

author

2015-04-29 00:08 UTC #27 lore raw

On 29/04/2015 07:10, Jan Beulich wrote

Quoted 24 lines

Quoted 24 lines
Quoted 1 line
Quoted 1 line
"Wang, Wei W" <[email protected]> 04/28/15 4:38 PM >>>
On 28/04/2015 21:29, Jan Beulich wrote
Quoted 21 lines
Quoted 12 lines
Quoted 1 line
Quoted 1 line
"Wang, Wei W" <[email protected]> 04/28/15 3:24 PM >>>
On 28/04/2015 21:14, Jan Beulich wrote
Quoted 10 lines
Quoted 7 lines
On 25/04/2015 00:15, Konrad Rzeszutek Wilk wrote
Quoted 2 lines
How will this affect AMD processors which can use the cpufreq? Would the ondemand feature go away?
No, this won't affect them. When the "intel_pstate=disable" is added to the booting parameter list, the old cpufreq driver will be used, and everything, including xenpm, will work in the old style.
That wouldn't suffice. On AMD (and older Intel) platforms it shouldn't be necessary to specifiy the option to retain current
functionality.
Quoted 3 lines
No problem, I will change it with "intel_pstate=enable" to enable the intel_pstate driver. Then others will not be bothered.
For new code this might be a good idea anyway, but that wasn't my point. Instead, even with "intel_pstate=enable" on an old Intel (or AMD) system (regardless of doing so being pointless) there shouldn't be any behavioral difference.

Quoted 8 lines

Quoted 1 line
Without " intel_pstate=enable" added, the old acpi-cpufreq driver will be
loaded, so shouldn't be a problem.
While I would have thought this to be an obvious thing anyway, it looks like we still don't understand each other. As much as it is (supposed to be) natural that in the absence of that command line option things behave as before, it should also be so if the option _was_ given but the driver didn't find suitable hardware.

The intel_pstate driver will check if the running CPU is included in the table which contains all the supported CPUs. If not, we can unregister the intel_pstate driver and have the old one loaded.

Best,
Wei