Re: [Xen-devel] Slow guest network I/O when CPU is pegged - Looking for acknowledgement from developers

[Pasi Kärkkäinen <pasik@xxxxxx>]

On Thu, Apr 13, 2006 at 09:52:19AM -0400, Matt Ayres wrote:
> 
> 
> Keir Fraser wrote:
> >
> >On 7 Apr 2006, at 19:25, Matt Ayres wrote:
> >
> >>Ok, so we all know that guest network I/O is slow when the system 
> >>CPU's are being utilized extensively whether it be from dom0 or from 
> >>other guests.  Lots of people have written about this and I can post 
> >>concrete tests if required.
> >>
> >>I'm just looking for one of the Xen developers to acknowledge that 
> >>they have been able to replicate the problem and it is indeed being 
> >>worked on or will be sometime in the near future.  No one has 
> >>acknowledged any of the previous threads on either list so I want to 
> >>make sure it is an outstanding issue that is not being overlooked.
> >
> >It depends on the setup but poor scheduling is the main reason for poor 
> >network performance, usually. SEDF seems to have some problems with 
> >real-time domains (like domain0 with its default scheduling parameters) 
> >and gives them all the CPU they want -- this is obviously going to be 
> >bad if a client domain is scheduled on the same CPU. 
> 
> You hit it right here.  I did some thinking and informal tests and came 
> to a conclusion.  The SEDF is the "new kid" on the block and it also the 
> default, hence everyone is using it.  In many cases (such as mine) 
> people are just using SEDF with the weight.  Also, extratime seems to be 
> broken (according to Stephen in an old post) and doesn't work well with 
> heavy I/O.  It especially doesn't do well when dom0 does anything else 
> but provide block and network device access, even when it is tuned in 
> proportion to the other VM weights.
> 
> Another argument is that the SEDF scheduler is just TOO good at what it 
> does, in that case it needs some work done to be more flexible.  Users 
> should consider and test both schedulers before making a decision on 
> which to use, there is no clear "winner".
> 
> Why am I replying? I did my tests.  BVT is nowhere near as strict as 
> SEDF in it's "while 1" tests as far as allocating CPU to domains, but it 
> seems to do a good enough job of providing a proportional share based on 
> weight (duh) in a real world production environment.  It also fixed my 
> network throughput problem.
> 
> Thanks,
> Matt
> 

It seems BVT was the recommended CPU scheduler in Xen 2. I think I'll have
to try it too.. I hope it will fix the network throughput problems I'm
seeing in Xen 3.

Are there any downsides in using BVT scheduler in Xen 3.0 ? Why was the
default changed from BVT -> SEDF ?

-- Pasi

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel