Re: physical memory limit of 64-bit linux

[Jeremy Fitzhardinge]

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