Linux kernel -stable discussions
 help / color / mirror / Atom feed
* [PATCH] x86: Fix booting with DEBUG_PAGE_ALLOC with more than 512G RAM
       [not found] <52090CF2.3040505@sr71.net>
@ 2013-08-12 23:43 ` Yinghai Lu
  2013-08-12 23:50   ` Dave Hansen
  0 siblings, 1 reply; 3+ messages in thread
From: Yinghai Lu @ 2013-08-12 23:43 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: Ingo Molnar, linux-kernel, Dave Hansen, Yinghai Lu, stable

Dave reported that system have early crash if DEBUG_PAGEALLOC is selected,
when system have between 500G and 600G.

> [    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
> [    0.000000]  [mem 0x00000000-0x000fffff] page 4k
> [    0.000000] BRK [0x02086000, 0x02086fff] PGTABLE
> [    0.000000] BRK [0x02087000, 0x02087fff] PGTABLE
> [    0.000000] BRK [0x02088000, 0x02088fff] PGTABLE
> [    0.000000] init_memory_mapping: [mem 0xe80ee00000-0xe80effffff]
> [    0.000000]  [mem 0xe80ee00000-0xe80effffff] page 4k
> [    0.000000] BRK [0x02089000, 0x02089fff] PGTABLE
> [    0.000000] BRK [0x0208a000, 0x0208afff] PGTABLE
> [    0.000000] Kernel panic - not syncing: alloc_low_page: ran out of memory

It turns out that we missed increasing needed pages in BRK to mapping
initial 2M and [0,1M) when we switch to use #PF handler set mem mapping.

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

Reported-by: Dave Hansen <dave.hansen@intel.com>
Bisected-by: Dave Hansen <dave.hansen@intel.com>
Tested-by: Dave Hansen <dave.hansen@intel.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: <stable@vger.kernel.org> 3.9+

---
 arch/x86/mm/init.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: linux-2.6/arch/x86/mm/init.c
===================================================================
--- linux-2.6.orig/arch/x86/mm/init.c
+++ linux-2.6/arch/x86/mm/init.c
@@ -78,8 +78,8 @@ __ref void *alloc_low_pages(unsigned int
 	return __va(pfn << PAGE_SHIFT);
 }
 
-/* need 4 4k for initial PMD_SIZE, 4k for 0-ISA_END_ADDRESS */
-#define INIT_PGT_BUF_SIZE	(5 * PAGE_SIZE)
+/* need 3 4k for initial PMD_SIZE,  3 4k for 0-ISA_END_ADDRESS */
+#define INIT_PGT_BUF_SIZE	(6 * PAGE_SIZE)
 RESERVE_BRK(early_pgt_alloc, INIT_PGT_BUF_SIZE);
 void  __init early_alloc_pgt_buf(void)
 {

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] x86: Fix booting with DEBUG_PAGE_ALLOC with more than 512G RAM
  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
  0 siblings, 1 reply; 3+ messages in thread
From: Dave Hansen @ 2013-08-12 23:50 UTC (permalink / raw)
  To: Yinghai Lu; +Cc: H. Peter Anvin, Ingo Molnar, linux-kernel, stable

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.



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] x86: Fix booting with DEBUG_PAGE_ALLOC with more than 512G RAM
  2013-08-12 23:50   ` Dave Hansen
@ 2013-08-12 23:59     ` Yinghai Lu
  0 siblings, 0 replies; 3+ messages in thread
From: Yinghai Lu @ 2013-08-12 23:59 UTC (permalink / raw)
  To: Dave Hansen
  Cc: H. Peter Anvin, Ingo Molnar, Linux Kernel Mailing List,
	stable@vger.kernel.org

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2013-08-12 23:59 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <52090CF2.3040505@sr71.net>
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 is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox