Re: [BENCHMARK] 2.5.68-mm3 with contest

[Andrew Morton <akpm@digeo.com>]

Con Kolivas <kernel@kolivas.org> wrote:
>
> All the io-write based loads were affected. 

Yup.  Mainly because the large queue increases truncate latencies.

gcc needs to delete a file.  truncate needs to wait on all in-progress
writeout against that file before releasing the blocks.  With the larger
queue that takes a lot longer.

Could be fixed with a global buffer cache (leave the IO in progress against
the freed block, only wait on it if the block is reallocated).  But we
don't have a global buffer cache.

Could be fixed with an IO cancellation capability at the request layer. 
has been discussed, is tricky.

Could be fixed by waiting on any pending IO at reallocation time at the
disk request layer, not the buffercache layer.  This could be made to work
OK with the rbtree-based request lookup actually.  But it'd hammer the heck
out of the request lookup code and the lock contention on big SMP would be
large.

Could be fixed by reducing the queue size again ;) This is what we'll do. 
There isn't a lot of benefit in the large queues.  -mm3 really only has the
big queue to demonstrate that the VM/VFS behaviour is now decoupled from
queue size, and for people to play with it.