| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Slow guest network I/O when CPU is pegged - Looking for
On Thu, Apr 13, 2006 at 09:52:19AM -0400, Matt Ayres wrote:
>
>
> 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
>
It seems BVT was the recommended CPU scheduler in Xen 2. I think I'll have
to try it too.. I hope it will fix the network throughput problems I'm
seeing in Xen 3.
Are there any downsides in using BVT scheduler in Xen 3.0 ? Why was the
default changed from BVT -> SEDF ?
-- Pasi
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home