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.pod.1 | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'docs/man/xl.pod.1') 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. -- cgit v1.2.3