Re: RFC: CONFIG_PAGE_SHIFT (aka software PAGE_SIZE)

[Rene Herman <rene.herman@gmail.com>]

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.