Thread (3 messages) 3 messages, 2 authors, 2013-08-12

Re: [PATCH] x86: Fix booting with DEBUG_PAGE_ALLOC with more than 512G RAM

From: Yinghai Lu <yinghai@kernel.org>
Date: 2013-08-12 23:59:04
Also in: lkml

On Mon, Aug 12, 2013 at 4:50 PM, Dave Hansen [off-list ref] wrote:
On 08/12/2013 04:43 PM, Yinghai Lu wrote:
quoted
quoted
quoted
commit 8170e6bed465b4b0c7687f93e9948aca4358a33b
Author: H. Peter Anvin [off-list ref]
Date:   Thu Jan 24 12:19:52 2013 -0800

    x86, 64bit: Use a #PF handler to materialize early mappings on demand
Before that, we have maping from [0,512M) in head_64.S, and we can
spare two pages [0-1M).  After that change, we can not reuse pages anymore.

When we have more than 512M ram, we need extra page for pgd page with
[512G, 1024g).

Increase pages in BRK for page table to solve the booting problem.
So how much does this get us up to?  1TB?  That's actually _fairly_
small today.  I've got a fairly old machine with that much in it, and
it's only half full of DIMMs.

It's also a bit worrying that this is completely disconnected from the
other code in the kernel that is concerned with the amount of total
address space in the system: MAX_PHYSADDR_BITS.
3 pages for [0,1M)
3 pages for initial 2M. ( it is 2M alignment).
are enough.

one page for PGD page (cover 512g), one page for PUD page (cover 1G)
and one page for PMD page (cover 2M).

After initial 2M is mapped, we will use that mapped 2M for other
memory range page table buffer.

Thanks

Yinghai
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help