Cc: Christoph Lameter <clameter@...>, <linux-kernel@...>, Mel Gorman <mel@...>, William Lee Irwin III <wli@...>, Jens Axboe <jens.axboe@...>, Badari Pulavarty <pbadari@...>, Maxim Levitsky <maximlevitsky@...>, Nick Piggin <nickpiggin@...>
On Sat, 28 Apr 2007 03:34:32 +1000 David Chinner <dgc@sgi.com> wrote:
1-disk and 2-disk read throughput fell by an improbable amount, which makes
me cautious about the other numbers.
Your annotation says "blocksize". Are you really varying the fs blocksize
here, or did you mean "pagesize"?
What worries me here is that we have inefficient code, and increasing the
pagesize amortises that inefficiency without curing it.
If so, it would be better to fix the inefficiencies, so that 4k pagesize
will also benefit.
For example, see __do_page_cache_readahead(). It does a read_lock() and a
page allocation and a radix-tree lookup for each page. We can vastly
improve that.
Step 1:
- do a read-lock
- do a radix-tree walk to work out how many pages are missing
- read-unlock
- allocate that many pages
- read_lock()
- populate all the pages.
- read_unlock
- if any pages are left over, free them
- if we ended up not having enough pages, redo the whole thing.
that will reduce the number of read_lock()s, read_unlock()s and radix-tree
descents by a factor of 32 or so in this testcase. That's a lot, and it's
something we (Nick ;)) should have done ages ago.
Step 2 is pretty obvious: __do_page_cache_readahead() is now in an ideal
position to parse its list of missing-pgoff_t's and to perform higher-order
allocations to satisfy any power-of-2-sized-and-aligned holes in the
pagecache. Fix up your lameo HBA for reads.
Step 1 is a glaring inefficiency, which large PAGE_CACHE_SIZE attempts to
work around for some subset of cases. It's better to fix the inefficiency
at its core. There are others. Kernel profiles, please.
-
