All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Ayres <matta@tektonic.net>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: Slow guest network I/O when CPU is pegged - Looking for acknowledgement from developers
Date: Thu, 13 Apr 2006 09:52:19 -0400	[thread overview]
Message-ID: <443E5793.9070202@tektonic.net> (raw)
In-Reply-To: <0797add807a6e104a2f5e44a7c76f552@cl.cam.ac.uk>



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

  parent reply	other threads:[~2006-04-13 13:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-07 18:25 Slow guest network I/O when CPU is pegged - Looking for acknowledgement from developers Matt Ayres
2006-04-08  7:56 ` Keir Fraser
2006-04-10 10:09   ` Pasi Kärkkäinen
2006-04-13 13:52   ` Matt Ayres [this message]
2006-04-19 17:15     ` Pasi Kärkkäinen
2006-04-19 19:46       ` Anand Gupta
2006-04-19 19:55         ` Rob Gardner
2006-04-19 20:12           ` Anand Gupta
2006-04-19 20:14       ` Anand Gupta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=443E5793.9070202@tektonic.net \
    --to=matta@tektonic.net \
    --cc=Keir.Fraser@cl.cam.ac.uk \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.