From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Subject: Re: poor domU VBD performance. Date: Thu, 31 Mar 2005 19:43:12 +0200 Message-ID: <20050331174312.GR9204@suse.de> References: <20050331070514.GH9204@suse.de> <20050331071043.GI9204@suse.de> <63537e2b84ddbba6cb3d970f73c6ab35@cl.cam.ac.uk> <20050331081900.GK9204@suse.de> <20050331143312.GB13179@vienna.egenera.com> <20050331153449.GE12579@tpkurt.garloff.de> <20050331153925.GP9204@suse.de> <20050331154130.GQ9204@suse.de> <424C24F2.1040002@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <424C24F2.1040002@us.ibm.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Nivedita Singhvi Cc: Ian Pratt , Xen development list , Kurt Garloff , Philip R Auld , Vincent Hanquez , Christian Limpach List-Id: xen-devel@lists.xenproject.org On Thu, Mar 31 2005, Nivedita Singhvi wrote: > Jens Axboe wrote: > > >There are still cases where it will be suboptimal of course, I didn't > >intend to claim it will always be as fast as queue tracking! If you are > >unlucky enough that the first request will reach the target device and > >get started before the next one, you will have a small and a large part > >of any given request executed. This isn't good for performance, > >naturally. But queueing is so fast, I would be surprised if this > >happened much in the real world. > > Although the usual answer for what scheduling algorithm is > best is almost always "depends on the workload", it was > suggested to me that the cfq was still the best option to > go with. What do people feel about that? (Or is AS going > to remain default?). Really the only one that you should not use is AS, anything else will be fine. AS should only ever be used at the bottom of the stack, if on a single spindle backing. CFQ will be fine, as will deadline and noop. > Also, we're making the assumption here that guest OS = virtual > driver/device. I would rather we not make that assumption > always. This may be moot because I was also told there might > be a patch floating around (-mm ?) that allows you to > select scheduling algorithm on a per-device basis. Anyone > know if this is going to come in anytime soon? That patch is in mainline since 2.6.10. You can change schedulers by echoing the preferred scheduler to /sys/block//queue/scheduler - reading that file will show you what schedulers are available. -- Jens Axboe