Re: Credit scheduler

[Mats Petersson <mats@planetcatfish.com>]

At 08:30 13/07/2007, Atsushi SAKAI wrote:
>Hi, Prabha
>
>pak333@comcast.net wrote:
>
>[snip]
>
> > > >Also, if the IO VM requests an IO, it will block and dom0 wakes up
> > > >and gets scheduled to run to service the IO. Will it preempt the cpu
> > > >intensive VM. If so why? Shouldn't the cpuintensiveV M get its
> > > >quantum of time.
> > > >Or does the IOVM get higher priority to preempt the cpu intensive
> > > >VM. How does the scheduler pick which cpu to run dom0 on ( if all
> > > >the vcpus running are cpu intensive)? If there is a mix of cpu-vcpus
> > > >and Io-vcpus, which will be the victim
> > >
> > >
> > > The whole idea of having separate queues for IO and CPU intensive VMs
> > > (or processes in a normal kernel scenario) is to allow the
> > > IO-intensive tasks to avoid waiting for the next time-slot when a
> > > CPU-hogging VM/process is running [1]. The normal behaviour for the
> > > scheduler is to determine dynamically if the current VM/process is IO
> > > or CPU intensive.
> > >
> > > Unless Dom0 is used for doing some silly CPU-intensive task
> > > (calculating PI with a million decimal points or compiling Xen +
> > > Linux kernel, for example), it will most likely look to the scheduler
> > > like a IO-intensive VM. So it will have the same priority as any
> > > other IO-intensive VM (assuming Dom0 has equal scheduler parameters
> > > as other guests, which I'm pretty sure is the default behaviour).
> > >
> > Does dom0 have a higher pritority than any CPU intensive VM
>
>Easy way is to set higher weight to dom0.
>(This makes get higher priority like I/O intensive domain for domain
>dispatch)
>
>If you want to set higher priority of Dom0 see follow patch.
>(This is sample patch for boost Dom0 only not boost I/O intensive.)
>http://lists.xensource.com/archives/html/xen-devel/2007-05/msg00529.html
>
>Or just set  CSCHED_PRI_TS_BOOST   for domain0
>in case dom0 priority is  CSCHED_PRI_TS_UNDER.
>
>
> > > If, like in your example, there are a number of processors busy with
> > > CPU-intensive tasks, and others with IO-intensive tasks, the most
> > > likely scenario is that any new IO-request will go be run on a
> > > "previously CPU-intensive" CPU - but on the other hand, if you have a
> > > lot of IO-intensive processing, there should be some processor(s)
> > > that are "asleep" - unless all CPU's are busy running 
> CPU-intensive tasks...
> > But will it preempt a CPU intensive vcpu if no cpu is available
>
>[snip]
>
> > >
> > > [1] The idea being that if we process the IO-request that just
> > > completed, we can set up another IO-request, and this will get better
> > > IO-throughput than waiting a long time (relatively speaking 30ms is
> > > an eternity to the processor).
> > Don't understand what you mean here.
>
>I guess Mats suggests to use AIO.

Well, sort of. I meant the idea behind waking an IO-intensive process 
by pre-empting a CPU intensive process is that it improves the 
overall IO throughput, because very often, once one IO request is 
completed, another one will be requested. Hardware will take some 
time to proces each request, at which time it's fine to run the 
CPU-intensive process. If you prevent the IO intensive task from 
running until the CPU-intensive task has exhausted it's time, it's 
obviously going to take longer before the next IO-request is started, 
and thus longer until it gets completed. It makes little difference 
here if the APPLICATION is asynchronously or synchronously issuing 
the IO-request (assuming that under asynchronous circumstances there 
is a LIMITED amount of AIO queue - else it becomes a CPU-intensive 
task building until it's issued all of the IO-requests and fall asleep).

--
Mats


>Thanks
>Atsushi SAKAI