Cc: Goswin von Brederlow <brederlo@...>, Andrew Morton <akpm@...>, Joern Engel <joern@...>, Nick Piggin <nickpiggin@...>, Christoph Lameter <clameter@...>, <torvalds@...>, <linux-fsdevel@...>, <linux-kernel@...>, Christoph Hellwig <hch@...>, William Lee Irwin III <wli@...>, David Chinner <dgc@...>, Jens Axboe <jens.axboe@...>, Badari Pulavarty <pbadari@...>, Maxim Levitsky <maximlevitsky@...>, Fengguang Wu <fengguang.wu@...>, swin wang <wangswin@...>, <totty.lu@...>, <hugh@...>
On Sun, Sep 16, 2007 at 07:15:04PM +0100, Mel Gorman wrote:
Well not sure about the 16MB number, since I'm unsure what the size of
the ram was. But clearly I agree there are fragmentation issues in the
slab too, there have always been, except they're much less severe, and
the slab is meant to deal with that regardless of the PAGE_SIZE. That
is not a new problem, you are introducing a new problem instead.
We can do a lot better than slab currently does without requiring any
defrag move-or-shrink at all.
slab is trying to defrag memory for small objects at nearly zero cost,
by not giving pages away randomly. I thought you agreed that solving
the slab fragmentation was going to provide better guarantees when in
another email you suggested that you could start allocating order > 0
pages in the slab to reduce the fragmentation (to achieve most of the
guarantee provided by config-page-shift, but while still keeping the
order 0 at 4k for whatever reason I can't see).
You ignore one other bit, when "/usr/bin/free" says 1G is free, with
config-page-shift it's free no matter what, same goes for not mlocked
cache. With variable order page cache, /usr/bin/free becomes mostly a
lie as long as there's no 4k fallback (like fsblock).
And most important you're only tackling on the pagecache and I/O
performance with the inefficient I/O devices, the whole kernel has no
cahnce to get a speedup, infact you're making the fast paths slower,
just the opposite of config-page-shift and original Hugh's large
PAGE_SIZE ;).
-
