| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] Re: poor domU VBD performance.
Has anyone looked into using the other schedulers? Potentially noop or
deadline for Dom0 with deadline or anticipatory for DomUs , or go the
other way - noop/deadline in DomUs and cfq/deadline in Dom0? It
actually make some sense that DomU performance would be degraded from
Dom0's as the request has to go through it's scheduler (which typically
was designed to run async with some "fairness queuing") which is limited
by XEN's bvt scheduler and then Dom0's disk i/o scheduler which is also
limited by XEN's bvt scheduler (doesn't it?) Enabling/Disabling
Preemptible Kernel may also provide some light on the situation.
If this becomes an item open to modification for performance reasons,
I'd prefer to have Dom0 set the performance of the DomU's. It wouldn't
really matter for the moment, but once DomU's get to boot their own
kernel (as in hosting services providing xen'd servers/services where
the client can compile their own kernel - which has been talked about -
this will become a requirement/feature request).
I was actually going to do some testing in these areas, but my test box
(AMD 3000+/water cooled) overheated and fried the northbridge/memory.
Oh, the joys of living in the tropics ;-) A new MB (upgraded to AMD64)
should arrive end of the week or early next week so I can test then if
no one else get around to it.
Regards,
Brian.
On Tue, 2005-03-29 at 09:38, Ian Pratt wrote:
> > "dd if=/dev/hde1 of=/dev/null bs=1024k count=1024"
> >
> > in domU.
> >
> > hdparm told that the default setup was 256k readahead.
>
> Do you mean KB or sectors?
>
> > I have tested the performance with the following readahead settings:
> >
> > readahead | duration
> > 128 sectors | 160 sec
> > 256 sectors | 76 sec
> > 512 sectors | 18.5 sec
> > 1024 sectors | 19.5 sec
> > 1200 sectors | 457 sec
> > dom0 takes 18.0 secs no matter of the readahead setting in Dom0 is.
>
> Would you mind repeating these experiments with a 2.4 dom0 and a 2.6domU
> ?
>
> The performance cliff below 512 and above 1024 sectors is spectacular.
> This is all rather confusing, but at least we know it can be made to
> work fast. Changing the domU readahead is unlikely to be the right fix.
> We just need to figure out how to keep it on the sweet spot...
> Thanks,
> Ian
>
>
> _______________________________________________
> 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
|
|
|
| |
|
Home