Re: RFC: CONFIG_PAGE_SHIFT (aka software PAGE_SIZE)

Rene Herman
2007-07-19T00:54:47Z

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.