linux-kernel - Re: RFC: CONFIG_PAGE_SHIFT (aka software PAGE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <469EB604.50000@gmail.com>
Date:	Thu, 19 Jul 2007 02:53:24 +0200
From:	Rene Herman <rene.herman@...il.com>
To:	Andrea Arcangeli <andrea@...e.de>
CC:	William Lee Irwin III <wli@...omorphy.com>,
	Dave Hansen <haveblue@...ibm.com>,
	linux-kernel@...r.kernel.org,
	Dave Kleikamp <shaggy@...ux.vnet.ibm.com>
Subject: Re: RFC: CONFIG_PAGE_SHIFT (aka software PAGE_SIZE)

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/