From: Yinghai Lu <yinghai@kernel.org>
To: Dave Hansen <dave.hansen@intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH] x86: Fix booting with DEBUG_PAGE_ALLOC with more than 512G RAM
Date: Mon, 12 Aug 2013 16:59:00 -0700 [thread overview]
Message-ID: <CAE9FiQXZ5qgsiyat_KYArJnEdi1O_q3ybdSHj3OehmEK+GG4hg@mail.gmail.com> (raw)
In-Reply-To: <520974DC.60802@intel.com>
On Mon, Aug 12, 2013 at 4:50 PM, Dave Hansen <dave.hansen@intel.com> wrote:
> On 08/12/2013 04:43 PM, Yinghai Lu wrote:
>>> > commit 8170e6bed465b4b0c7687f93e9948aca4358a33b
>>> > Author: H. Peter Anvin <hpa@zytor.com>
>>> > 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
next prev parent reply other threads:[~2013-08-12 23:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-09 23:18 x86: early boot crash: "alloc_low_page: ran out of memory" (bisected) Dave Hansen
2013-08-09 23:23 ` Yinghai Lu
2013-08-10 1:19 ` Dave Hansen
2013-08-10 2:10 ` Yinghai Lu
2013-08-10 2:21 ` Yinghai Lu
2013-08-12 16:27 ` Dave Hansen
2013-08-12 23:43 ` [PATCH] x86: Fix booting with DEBUG_PAGE_ALLOC with more than 512G RAM Yinghai Lu
2013-08-12 23:50 ` Dave Hansen
2013-08-12 23:59 ` Yinghai Lu [this message]
2013-08-20 8:22 ` [tip:x86/urgent] x86/mm: Fix boot crash with DEBUG_PAGE_ALLOC= y and " tip-bot for Yinghai Lu
2013-08-12 23:47 ` x86: early boot crash: "alloc_low_page: ran out of memory" (bisected) Yinghai Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAE9FiQXZ5qgsiyat_KYArJnEdi1O_q3ybdSHj3OehmEK+GG4hg@mail.gmail.com \
--to=yinghai@kernel.org \
--cc=dave.hansen@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).