[lkml]   [2010]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH][RF C/T/D] Unmapped page cache control - via boot parameter
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

 \ /
  Last update: 2010-03-17 18:09    [W:0.111 / U:2.500 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site