|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] Slow guest network I/O when CPU is pegged - Looking for
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|