WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Matt Ayres <matta@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Slow guest network I/O when CPU is pegged - Looking for acknowledgement from developers
From: Pasi Kärkkäinen <pasik@xxxxxx>
Date: Wed, 19 Apr 2006 20:15:09 +0300
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 19 Apr 2006 10:15:29 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <443E5793.9070202@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4436AE88.1080200@xxxxxxxxxxxx> <0797add807a6e104a2f5e44a7c76f552@xxxxxxxxxxxx> <443E5793.9070202@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
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