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: Keir Fraser <Keir.Fraser@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: Mon, 10 Apr 2006 13:09:32 +0300
Cc: Matt Ayres <matta@xxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 10 Apr 2006 03:09:52 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <0797add807a6e104a2f5e44a7c76f552@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
On Sat, Apr 08, 2006 at 08:56:19AM +0100, 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. Since UDP has no 
> flow control, dom0 can keep itself busy generating or forwarding UDP 
> packets to the domU that get dropped continually in netback driver. 
> DomU will hardly ever get scheduled. Even in the case of TCP, any drops 
> will be interpreted as congestion and transmit rate will be cut.
> 
> Basically I think the SEDF scheduler needs cleaning up: probably by 
> removing the mass of confusing conditionally compiled options and then 
> focusing on the remaining code that is actually compiled in. Another 
> option is to try specifying the BVT scheduler and see if that works 
> better. Or try setting dom0 to have non-real-time guarantees. Or give 
> dom0 its own hyperthread on an Intel system (strongly recommended if 
> it's possible).
> 

Has anyone already tried this? I'd like to know if dedicating own
hyperthread for dom0 helps to fix these network performance problems..


> Apart from that, if you really are genuinely loading up CPUs with 
> CPU-intensive workloads, and expecting them also to be able to process 
> a significant amount of network traffic then something has to give. You 
> can only run CPUs at 100%.
> 
>   -- Keir
> 
> 

-- Pasi
       
                                   ^
                                .     .
                                 Linux
                              /    -    \
                             Choice.of.the
                           .Next.Generation.

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