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
| ||
|
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/
Powered by blists - more mailing lists