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

[Hans-Christian Armingeon <mog.johnny@xxxxxxx>]

Hi,

Am Mittwoch, 12. April 2006 18:22 schrieb Stephen C. Tweedie:
> Hi,
> 
> 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
> performance.

What would be a better scheduler setting?
Could you point me to some docs?

I found only little documentation about xen and schedulers.

Many thanks in advance,

Johnny

> 
> 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.
> 
> --Stephen
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 

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