From 4015145b148121d9647d8a2abe897aabb7197c95 Mon Sep 17 00:00:00 2001 From: George Dunlap Date: Tue, 11 Jun 2013 13:31:38 +0100 Subject: docs: Make note for the scheduler "cap" option warning about power management effects Suggested-by: Massimo Canonico Signed-off-by: George Dunlap Reviewed-by: Dario Faggioli Acked-by: Ian Campbell --- docs/man/xl.cfg.pod.5 | 13 +++++++++++++ docs/man/xl.pod.1 | 13 +++++++++++++ docs/man/xm.pod.1 | 13 +++++++++++++ 3 files changed, 39 insertions(+) (limited to 'docs') diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 index b7d64a6d7d..069b73ff60 100644 --- a/docs/man/xl.cfg.pod.5 +++ b/docs/man/xl.cfg.pod.5 @@ -153,6 +153,19 @@ The cap is expressed in percentage of one physical CPU: The default, 0, means there is no upper cap. Honoured by the credit and credit2 schedulers. +NB: Many systems have features that will scale down the computing +power of a cpu that is not 100% utilized. This can be in the +operating system, but can also sometimes be below the operating system +in the BIOS. If you set a cap such that individual cores are running +at less than 100%, this may have an impact on the performance of your +workload over and above the impact of the cap. For example, if your +processor runs at 2GHz, and you cap a vm at 50%, the power management +system may also reduce the clock speed to 1GHz; the effect will be +that your VM gets 25% of the available power (50% of 1GHz) rather than +50% (50% of 2GHz). If you are not getting the performance you expect, +look at performance and cpufreq options in your operating system and +your BIOS. + =item B The normal EDF scheduling usage in nanoseconds. This means every period diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1 index 57c6a79174..0e2fe6569b 100644 --- a/docs/man/xl.pod.1 +++ b/docs/man/xl.pod.1 @@ -848,6 +848,19 @@ is expressed in percentage of one physical CPU: 100 is 1 physical CPU, 50 is half a CPU, 400 is 4 CPUs, etc. The default, 0, means there is no upper cap. +NB: Many systems have features that will scale down the computing +power of a cpu that is not 100% utilized. This can be in the +operating system, but can also sometimes be below the operating system +in the BIOS. If you set a cap such that individual cores are running +at less than 100%, this may have an impact on the performance of your +workload over and above the impact of the cap. For example, if your +processor runs at 2GHz, and you cap a vm at 50%, the power management +system may also reduce the clock speed to 1GHz; the effect will be +that your VM gets 25% of the available power (50% of 1GHz) rather than +50% (50% of 2GHz). If you are not getting the performance you expect, +look at performance and cpufreq options in your operating system and +your BIOS. + =item B<-p CPUPOOL>, B<--cpupool=CPUPOOL> Restrict output to domains in the specified cpupool. diff --git a/docs/man/xm.pod.1 b/docs/man/xm.pod.1 index 7c4ef851b0..4d47388eb2 100644 --- a/docs/man/xm.pod.1 +++ b/docs/man/xm.pod.1 @@ -767,6 +767,19 @@ is expressed in percentage of one physical CPU: 100 is 1 physical CPU, 50 is half a CPU, 400 is 4 CPUs, etc. The default, 0, means there is no upper cap. +NB: Many systems have features that will scale down the computing +power of a cpu that is not 100% utilized. This can be in the +operating system, but can also sometimes be below the operating system +in the BIOS. If you set a cap such that individual cores are running +at less than 100%, this may have an impact on the performance of your +workload over and above the impact of the cap. For example, if your +processor runs at 2GHz, and you cap a vm at 50%, the power management +system may also reduce the clock speed to 1GHz; the effect will be +that your VM gets 25% of the available power (50% of 1GHz) rather than +50% (50% of 2GHz). If you are not getting the performance you expect, +look at performance and cpufreq options in your operating system and +your BIOS. + =back =item B I I I I I -- cgit v1.2.3