Re: RFC: CONFIG_PAGE_SHIFT (aka software PAGE_SIZE)
From: Rene Herman
Date: Wed Jul 18 2007 - 20:54:48 EST
On 07/19/2007 01:50 AM, Andrea Arcangeli wrote:
On Wed, Jul 18, 2007 at 06:34:20PM +0200, Rene Herman wrote:
It says that highmem is not an issue due to no such thing as highmem even
existing on the machines with support for larger hard pagesizes, but this
wouldn't hold for soft pages. Sort of went "damn" in an x86 context upon
reading that.
Correct, but I'm not really sure if it worth worrying about x86
missing this
Larger softpages would nicely solve the "1-page stacks are sometimes small"
issue with 4KSTACKS on x86 that was discussed in another thread just now but
without tail packing, the pagecache slack would be too high a price to pay
given that loads that would actually benefit from it most definitely have
moved to 64-bit (although I'd certainly still want to try 8K as well, and
filesystems with larger blocksizes could be nice as well).
furthermore it would still be possible to enable it on the very x86 low
end (with regular 4k page size) that may worry to use up to the last byte
of ram as cache for tiny files.
But, yes, that's true, and I wonder if !HIGHMEM x86 will in fact be "very
low end" for long considering x86-64 is now _really_ here. Many people who
want enough memory to need highmem have probably already made the switch,
and in the embedded world, 896M (or 1G, or 2G with a adjusted split) is
still decidely non-low end. Yet a PVR, say, could love 64K pages for VM and
disk...
To me using kmalloc for this looks quite ideal.
Certainly simplest...
Rene.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/