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/
Home Products Support Community News


RE: [Xen-devel] ksoftirq/0 eating all cpu time

To: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] ksoftirq/0 eating all cpu time
From: "Stephen C. Tweedie" <sct@xxxxxxxxxx>
Date: Wed, 12 Apr 2006 12:22:03 -0400
Cc: Hans-Christian Armingeon <mog.johnny@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 12 Apr 2006 09:23:03 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <A95E2296287EAD4EB592B5DEEFCE0E9D4BA23C@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: <A95E2296287EAD4EB592B5DEEFCE0E9D4BA23C@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On Wed, 2006-04-12 at 16:58 +0100, Ian Pratt wrote:

> The default scheduling parameters are set assuming that the only thing
> running in dom0 is the control tool stack and the physical device
> drivers.
> If you're actually logged in and running stuff in dom0 then the defaults
> are terrible as they basically give dom0 much higher priority than
> everything else.

We may want to reconsider those defaults, as they can result in some
pathological cases even for the case where the dom0 is purely a service
OS.  There were results on the list a week or so ago from somebody
complaining about poor network performance: networking from a remote
host to a domU was dropping 99% or so of packets.  The problem was that
they were sending so much data that the dom0 was saturated, and the domU
never got a chance to see the incoming data; changing the scheduler
parameters to give the dom0 less priority actually vastly improved

This is a known problem for networking even on stock Linux without Xen,
as under extreme load you could in theory end up spending all your time
in network interrupts and starve the applications trying to consume the
data.  The NAPI networking code in Linux tries to deal with this by
enabling a polling mode precisely to avoid getting so bogged down.  It's
a similar case where you end up having to deprioritise your critical
handler in order to let the queues drain.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>