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: <20081216192354.GA843@elte.hu>
Date:	Tue, 16 Dec 2008 20:23:54 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
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


* Jeremy Fitzhardinge <jeremy@...p.org> wrote:

> 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.

[ i knew why i Cc:-ed you ;-) ]

>> 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 ;)

Only over my cold dead body ;-)

It would also be utterly impractical: it gives at most one or two more 
bits in practice before it starts breaking down seriously.

The thing that made highmem on 32-bit a necessity was the slow (and still 
ongoing) transition to the 64-bit world.

There's no such necessity at 48 bits - hw makers will just have to extend 
the pagetable bits in some suitable fashion, if they want to extend the 
number of the outgoing physical pins. There's no bitness migration hard 
barrier here.

[ I suspect other OSs are a lot less flexible about their x86-64 limits 
  than us. ]

[ And i hope i wont be around by the time we get close to the 64-bit limit
  ;-) If it ever happens (it is not sure it will) it will be seriously 
  unfunny. ]

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