|
Hi,
I have just tried playing
with the BVT CPU slice (context switch allowance in BVT scheduling) in Xen,
which is similar to the 'quantum' in timesharing scheduler. The default is
5ms.
Using the xc tool I intuitively
set 'xc cpu_bvtslice 10' aiming something like 10ms, that caused thrashing
in the system and I had to do a reboot.
The unit of the BVT slice is
actually in nanoseconds (ns) which I think it will be useful if it can be shown
in the xc usage menu. Setting it at 50,000ns still fine with only domain0, but
with more than 1 domain running (not even any CPU-bound processes) the
system will be thrashed by busy context switching. (I merely set the
slice back to normal so that I can still use the machine.)
I think anything lower than
100,000ns should be warned by the system in general for it to do anything useful
other than merely context switching. The BVT CPU slice is rarely changed and
leaving it at default surely is a good idea as I found that except there
are a couple of cpu-bound threads, otherwise Xenolinux
(domains>0) almost do a yield before their quantum is finished all
the time. In that case you may actually want to increase the slice.
Perhaps it's also worth to add
this in FAQ Jan?
Another question is that I wonder
if it will be desirable for the absolute scheduling to have two versions, one
for overall efficiency that do_yield() is allowed and another for strict
guarantee that do_yield() is somehow ignored until the effective quantum is due.
The former seems will not, in a long run, converge to the share that we want
easily as I found the timing that they do_yield() is quite random.
Cheers,
Yan-Ching CHU
| 
Home