Re: RFC: CONFIG_PAGE_SHIFT (aka software PAGE_SIZE)

[Andrea Arcangeli <andrea@suse.de>]

On Fri, Jul 13, 2007 at 05:13:08PM +1000, David Chinner wrote:
> Sure. Fundamentally, though, I think it is the wrong approach to
> take - it's a workaround for a big negative side effect of
> increasing page size. It introduces lots of complexity and
> difficult-to-test corner cases; judging by the tail packing problems
> reiser3 has had over the years, it has the potential to be a
> never-ending source of data corruption bugs.
> 
> I think that fine granularity and aggregation for efficiency of
> scale is a better model to use than increasing the base page size.
> With PPC, you can handle different page sizes in the hardware (like
> MIPS) and the use of 64k base page size is an obvious workaround to
> the problem of not being able to use multiple page sizes within the
> OS.

I think you're being too fs centric. Moving only the pagecache to a
large order is enough to you but it isn't enough to me, I'd like all
allocations to be faster, and I'd like to reduce the page fault
rate. The CONFIG_PAGE_SHIFT isn't just about I/O. It's just that
CONFIG_PAGE_SHIFT will give you the I/O side for free too.

Also keep in mind mixing multiple page sizes for different inodes has
the potential to screw the aging algorithms in the reclaim code. Just
to make an example during real random I/O over all bits of hot cache
in pagecache, a 64k page has 16 times more probability of being marked
young than a 4k page.

The tail packing of pagecache could very well be worth it. It should
cost nothing for the large files.

> Adding a workaround (tail packing) to address the negative side
> effects of another workaround (64k base page size) ignores the basic
> problem that has led to both these things being done: Linux does not
> support multiple page sizes natively.....

I understand you mean multiple page size in pagecache, but I see it as
a feature to keep the fast paths as fast as they can be.