From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Cc: Ian Jackson <ian.jackson@citrix.com>,
Massimo Canonico <mex@di.unipmn.it>,
Ian Campbell <ian.campbell@citrix.com>,
xen-devel@lists.xen.org
Subject: Re: [PATCH] docs: Make note for the scheduler "cap" option warning about power management effects
Date: Wed, 12 Jun 2013 09:57:10 -0400 [thread overview]
Message-ID: <20130612135710.GI2918@phenom.dumpdata.com> (raw)
In-Reply-To: <1370953898-10278-1-git-send-email-george.dunlap@eu.citrix.com>
On Tue, Jun 11, 2013 at 01:31:38PM +0100, George Dunlap wrote:
> Suggested-by: Massimo Canonico <mex@di.unipmn.it>
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> CC: Ian Campbell <ian.campbell@citrix.com>
> CC: Ian Jackson <ian.jackson@citrix.com>
> CC: Massimo Canonico <mex@di.unipmn.it>
> ---
> docs/man/xl.cfg.pod.5 | 13 +++++++++++++
> docs/man/xl.pod.1 | 13 +++++++++++++
> docs/man/xm.pod.1 | 13 +++++++++++++
> 3 files changed, 39 insertions(+)
>
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index b7d64a6..069b73f 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.
Or .. use 'cpufreq=xen:performance' ?
That should set it to the highest P state.
> +
> =item B<period=NANOSECONDS>
>
> 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 57c6a79..0e2fe65 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 7c4ef85..4d47388 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<sched-sedf> I<period> I<slice> I<latency-hint> I<extratime> I<weight>
> --
> 1.7.9.5
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
next prev parent reply other threads:[~2013-06-12 13:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-11 12:31 [PATCH] docs: Make note for the scheduler "cap" option warning about power management effects George Dunlap
2013-06-11 15:32 ` Massimo Canonico
2013-06-12 8:48 ` Dario Faggioli
2013-06-12 8:41 ` Dario Faggioli
2013-06-12 9:44 ` Ian Campbell
2013-06-12 9:58 ` Dario Faggioli
2013-06-12 13:57 ` Konrad Rzeszutek Wilk [this message]
2013-06-12 14:59 ` Ian Campbell
2013-06-12 15:01 ` George Dunlap
2013-06-14 18:38 ` Konrad Rzeszutek Wilk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130612135710.GI2918@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=george.dunlap@eu.citrix.com \
--cc=ian.campbell@citrix.com \
--cc=ian.jackson@citrix.com \
--cc=mex@di.unipmn.it \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.