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] n/w performance degradation

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] n/w performance degradation
From: Diwaker Gupta <diwaker.lists@xxxxxxxxx>
Date: Mon, 5 Dec 2005 16:04:19 -0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 06 Dec 2005 00:04:39 +0000
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mqd+yNJ454sOGkmHjDj2oqaPvj2NPBUq/plHuyVR0KJ3uXqXciV7gcTzseMkhQ4Gpvm6gAd3339q55v8HqPnDlXtrkJ0SjGx0u+XP0NpoZNFOflaL1V3SWRYw/ElNDhTQ7ebozTkg7OReV7p8VHS1qeOWMLuFQGlvmtgw30OuRI=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <ac41e395f221c825db7447f548ceacc8@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: <891be9410512051511x330e4efcnd113782c3496589a@xxxxxxxxxxxxxx> <ac41e395f221c825db7447f548ceacc8@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> We used to be able to saturate GigE with a single CPU, although

Same here.

> admittedly burning quite a bit more CPU than using dom0 as the
> endpoint. I guess things have got out of tune, but there are a bunch of
> things we could do to encourage I/O batching ('x packets or y
> milliseconds' style receive batching, and transmitting batches of
> packets every x milliseconds or when the domU goes idle). This,
> together with scheduler tuning, should definitely get the performance
> back, although its a balancing act with one CPU to ensure no stage of
> the I/O processing pipeline gets starved.

Look forward to it. Whats the deal with the pipelined backend? Whats
the target scenario there?

Meanwhile, though I agree that SMPs and hyperthreaded processors are
becoming the norm, it still doesn't solve this problem. Even on an SMP
machine, I can have dom0 co-located with a VM on the same CPU, and I'm
not sure how different that would be from the current situation.

On a related note, has anyone been working on the IDD stuff? Is it
possible to wrap up a device driver in its own domain? The last time 
I tried, it basically wasn't possible, but I'd really be interested in
helping out any which way to get it working.

Diwaker
--
Web/Blog/Gallery: http://floatingsun.net
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel