[Xen-changelog] [xen-4.2-testing] docs: Document scheduler-related Xen command-line options

[Xen patchbot-4.2-testing <patchbot@xxxxxxx>]

# HG changeset patch
# User George Dunlap <george.dunlap@xxxxxxxxxxxxx>
# Date 1351266143 -3600
# Node ID 325a4fdb7f3588b05b35475766e588bfa08c12ff
# Parent  1ecde3c0276481c371a42980b569c3fb78e108f1
docs: Document scheduler-related Xen command-line options

Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
Committed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>

xen-unstable changeset: 25968:91e8fd3cf266
Backport-requested-by: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Committed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
---


diff -r 1ecde3c02764 -r 325a4fdb7f35 docs/misc/xen-command-line.markdown
--- a/docs/misc/xen-command-line.markdown       Fri Oct 26 16:42:10 2012 +0100
+++ b/docs/misc/xen-command-line.markdown       Fri Oct 26 16:42:23 2012 +0100
@@ -701,12 +701,34 @@ Choose the default scheduler.
 ### sched\_credit\_tslice\_ms
 > `= <integer>`
 
+Set the timeslice of the credit1 scheduler, in milliseconds.  The
+default is 30ms.  Reasonable values may include 10, 5, or even 1 for
+very latency-sensitive workloads.
+
 ### sched\_ratelimit\_us
 > `= <integer>`
 
+In order to limit the rate of context switching, set the minimum
+amount of time that a vcpu can be scheduled for before preempting it,
+in microseconds.  The default is 1000us (1ms).  Setting this to 0
+disables it altogether.
+
 ### sched\_smt\_power\_savings
 > `= <boolean>`
 
+Normally Xen will try to maximize performance and cache utilization by
+spreading out vcpus across as many different divisions as possible
+(i.e, numa nodes, sockets, cores threads, &c).  This often maximizes
+throughput, but also maximizes energy usage, since it reduces the
+depth to which a processor can sleep.
+
+This option inverts the logic, so that the scheduler in effect tries
+to keep the vcpus on the smallest amount of silicon possible; i.e.,
+first fill up sibling threads, then sibling cores, then sibling
+sockets, &c.  This will reduce performance somewhat, particularly on
+systems with hyperthreading enabled, but should reduce power by
+enabling more sockets and cores to go into deeper sleep states.
+
 ### serial\_tx\_buffer
 > `= <size>`
 

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