On 03/17/2010 06:52 PM, Christoph Hellwig wrote:
On Wed, Mar 17, 2010 at 06:22:29PM +0200, Avi Kivity wrote:
They should be reorderable. Otherwise host filesystems on several
volumes would suffer the same problems.
They are reordable, just not as extremly as the the page cache.
Remember that the request queue really is just a relatively small queue
of outstanding I/O, and that is absolutely intentional. Large scale
_caching_ is done by the VM in the pagecache, with all the usual aging,
pressure, etc algorithms applied to it.
We already have the large scale caching and stuff running in the guest.
We have a stream of optimized requests coming out of guests, running the
same algorithm again shouldn't improve things. The host has an
opportunity to do inter-guest optimization, but given each guest has its
own disk area, I don't see how any reordering or merging could help here
(beyond sorting guests according to disk order).
The block devices have a
relatively small fixed size request queue associated with it to
facilitate request merging and limited reordering and having fully
set up I/O requests for the device.
We should enlarge the queues, increase request reorderability, and merge
flushes (delay flushes until after unrelated writes, then adjacent
flushes can be collapsed).
Collapsing flushes should get us better than linear scaling (since we
collapes N writes + M flushes into N writes and 1 flush). However the
writes themselves scale worse than linearly, since they now span a
larger disk space and cause higher seek penalties.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>