RE: [Xen-devel] BVT CPU Slice

["Neugebauer, Rolf" <rolf.neugebauer@xxxxxxxxx>]

>     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.

1) various other tools in dom0 have the safety catch off...you may shoot
yourself in the foot :) However, for the scheduler I think it would be
reasonable to check for sensible values. Furthermore, several other
people have moaned about the non-intuitiveness of some of the BVT
parameters. Again this can be changed trivially, I just haven't gotten
around doing it.

2) we plan to introduce at least another, alternative scheduler into
xen, one which offers absolute guarantees for the CPU. The idea is to be
able to select a scheduler either at boot time or compile time. Probably
sensible to introduce some checks, at least in the user level tools,
then. Maybe along the lines of the vbd expert mode, which also allows
you to shoot yourself in the foot if you want too, just makes it a bit
harder.


>    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.

I'm not sure I understand your reasoning here. If a domain wants to
yield let it yield. If it wants to block let it block. Then you have
some slack cpu time to play with. There is no point in just giving a
domain the cpu for it to burn it in the its idle loop. Mind you, any
domain might still do that, it is not mandated by xen that a domain
shall yield if it has nothing to do. However we might decide in Xen to
give preferential treatment to domains which do yield/block when it
comes to things like unblocking latencies etc. In fact, this already
implicitly happens with the current BVT implementation. IIRC the virtual
time borrowing only happens for unblocking domains but not to domains
which are already runable, which they would be if they never block.

Rolf
 



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel