linux-kernel - Re: physical memory limit of 64-bit linux

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: <4947FC68.4020603@goop.org>
Date:	Tue, 16 Dec 2008 11:07:20 -0800
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Ingo Molnar <mingo@...e.hu>
CC:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Martin Steigerwald <ms@...mix.de>,
	linux-kernel@...r.kernel.org, Andi Kleen <andi@...stfloor.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: physical memory limit of 64-bit linux

Ingo Molnar wrote:
> phase 3)  We could also go close to 47 bits: with various more invasive
>           movings of VMALLOC and rest upwards, and other considerations
>           such as the elimination of the generous start of 8 TB hole at
>           __PAGE_OFFSET - i.e. moving __PAGE_OFFSET straight down to
>           minus 128 TB. 120 TB would be doable.
>   

Originally it was there, but I moved it up because that's where Xen puts 
itself when running a PV 64-bit guest.  It is also properly 
parameterised now, so we could make it move on the basis of a config 
setting.

> phase 4)  If the 48 bits limit is ever lifted on the CPU side, we can move
>           __PAGE_OFFSET down. This is actually less invasive than phase 
>           3), because moving __PAGE_OFFSET is relatively easy. The far
>           more invasive change would be the necessary changes to the
>           virtual memory code: the current 4-level paging has a 256 TB 
>           limit which comes from the 512*512*512*512*4K split of 
>           pgd/pud/pmd/pte entries. Either PGDIR_SHIFT would have to be 
>           increased, moving the root pgtable's size from 4K to 8K or more, 
>           or another pgdir level would have to be introduced (which is 
>           even more intrusive and much less likely to be implemented by hw
>           makers).
>   

...or we could just reintroduce highmem ;)

    J
--
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/