All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yinghai Lu <yinghai@kernel.org>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [crash] Re: Latest brk patchset
Date: Mon, 16 Mar 2009 12:48:55 -0700	[thread overview]
Message-ID: <49BEAD27.3050801@kernel.org> (raw)
In-Reply-To: <49BEA7BE.6050400@goop.org>

Jeremy Fitzhardinge wrote:
> H. Peter Anvin wrote:
>> Jeremy Fitzhardinge wrote:
>>> Yinghai Lu wrote:
>>>> could be max_pfn_mapped change in head_32.S that reduce mapping
>>>> range to _end only.
>>>>   
>>>
>>> Yes, I would say you're right.  Trimming the mapping to _end only
>>> leaves the space under the kernel avaliable for allocating pagetable
>>> from e820 space.  In this case we've got DEBUG_PAGEALLOC enabled,
>>> which inhibits the use of PSE, and BIOS corruption checking on, which
>>> eats a chunk of low memory.  In combination, there's only 0x8f000
>>> bytes free below the kernel, and it needs 0xe1000 to allocate for
>>> pagetables.
>>>
>>> Reverting 2bd2753ff46346543ab92e80df9d96366e21baa5 fixes the problem
>>> for me, though it does result in a kernel with a 73MB BSS...
>>>
>>
>> Waitaminute... there is no way we could end up with 73 MB page tables
>> unless something is seriously screwy.  Even with PAE and !PSE, we only
>> get 2 MB worth of page tables for each 1 GB mapped -- even with a 4:4
>> scheme this is only 8 MB.
> 
> Yes, something odd happened there.
> 
> Anyway, this patch fixes it.  I also removed ALLOCATOR_SLOP, because it
> is left over from when we used the bootmem allocator for the linear
> mapping pagetable, before using e820 allocation.
> 
> Did you also want to pull the changes to put the brk in .brk and rename
> the reservation symbols?
> 
>    J
> 
> The following changes since commit
> 2bd2753ff46346543ab92e80df9d96366e21baa5:
>  Yinghai Lu (1):
>        x86: put initial_pg_tables into .bss
> 
> are available in the git repository at:
> 
>  ssh://master.kernel.org/~jeremy/git/xen.git tip/x86/setup-memory
> 
> Jeremy Fitzhardinge (2):
>      x86-32: make sure we map enough to fit linear map pagetables
>      x86-32: remove ALLOCATOR_SLOP from head_32.S
> 
> arch/x86/kernel/head_32.S |   32 ++++++++++++++++++++------------
> 1 files changed, 20 insertions(+), 12 deletions(-)
> 
>> From 378c46828de3f34d94d83f08b2d6d81a0fc8f108 Mon Sep 17 00:00:00 2001
> From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> Date: Mon, 16 Mar 2009 12:07:54 -0700
> Subject: [PATCH] x86-32: make sure we map enough to fit linear map
> pagetables
> 
> head_32.S needs to map the kernel itself, and enough space so
> that mm/init.c can allocate space from the e820 allocator
> for the linear map of low memory.
> 
> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> 
> diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
> index c79741c..e929619 100644
> --- a/arch/x86/kernel/head_32.S
> +++ b/arch/x86/kernel/head_32.S
> @@ -38,8 +38,8 @@
> #define X86_VENDOR_ID    new_cpu_data+CPUINFO_x86_vendor_id
> 
> /*
> - * This is how much memory *in addition to the memory covered up to
> - * and including _end* we need mapped initially.
> + * This is how much memory in addition to the memory covered up to
> + * and including _end we need mapped initially.
>  * We need:
>  *     (KERNEL_IMAGE_SIZE/4096) / 1024 pages (worst case, non PAE)
>  *     (KERNEL_IMAGE_SIZE/4096) / 512 + 4 pages (worst case for PAE)
> @@ -52,19 +52,28 @@
>  * KERNEL_IMAGE_SIZE should be greater than pa(_end)
>  * and small than max_low_pfn, otherwise will waste some page table entries
>  */
> -LOW_PAGES = (KERNEL_IMAGE_SIZE + PAGE_SIZE_asm - 1)>>PAGE_SHIFT
> 
> #if PTRS_PER_PMD > 1
> -PAGE_TABLE_SIZE = (LOW_PAGES / PTRS_PER_PMD) + PTRS_PER_PGD
> +#define PAGE_TABLE_SIZE(pages) (((pages) / PTRS_PER_PMD) + PTRS_PER_PGD)
> #else
> -PAGE_TABLE_SIZE = (LOW_PAGES / PTRS_PER_PGD)
> +#define PAGE_TABLE_SIZE(pages) ((pages) / PTRS_PER_PGD)
> #endif
> ALLOCATOR_SLOP = 4
> 
> -INIT_MAP_SIZE = (PAGE_TABLE_SIZE + ALLOCATOR_SLOP) * PAGE_SIZE_asm
> -RESERVE_BRK(pagetables, INIT_MAP_SIZE)
> +/* Enough space to fit pagetables for the low memory linear map */
> +MAPPING_BEYOND_END = (PAGE_TABLE_SIZE(1 << (32 - PAGE_SHIFT)) * PAGE_SIZE)

that is for 4g?

YH

> 
> /*
> + * Worst-case size of the kernel mapping we need to make:
> + * the worst-case size of the kernel itself, plus the extra we need
> + * to map for the linear map.
> + */
> +KERNEL_PAGES = (KERNEL_IMAGE_SIZE + MAPPING_BEYOND_END)>>PAGE_SHIFT
> +
> +INIT_MAP_SIZE = (PAGE_TABLE_SIZE(KERNEL_PAGES) + ALLOCATOR_SLOP) *
> PAGE_SIZE_asm
> +RESERVE_BRK(pagetables, INIT_MAP_SIZE)
> +   
> +/*
>  * 32-bit kernel entrypoint; only used by the boot CPU.  On entry,
>  * %esi points to the real-mode code as a 32-bit pointer.
>  * CS and DS must be 4 GB flat segments, but we don't depend on
> @@ -197,9 +206,9 @@ default_entry:
>     loop 11b
> 
>     /*
> -     * End condition: we must map up to the end.
> +     * End condition: we must map up to the end + MAPPING_BEYOND_END.
>      */
> -    movl $pa(_end) + PTE_IDENT_ATTR, %ebp
> +    movl $pa(_end) + MAPPING_BEYOND_END + PTE_IDENT_ATTR, %ebp
>     cmpl %ebp,%eax
>     jb 10b
> 1:
> @@ -229,9 +238,9 @@ page_pde_offset = (__PAGE_OFFSET >> 20);
>     addl $0x1000,%eax
>     loop 11b
>     /*
> -     * End condition: we must map up to end
> +     * End condition: we must map up to the end + MAPPING_BEYOND_END.
>      */
> -    movl $pa(_end) + PTE_IDENT_ATTR, %ebp
> +    movl $pa(_end) + MAPPING_BEYOND_END + PTE_IDENT_ATTR, %ebp
>     cmpl %ebp,%eax
>     jb 10b
>     addl $__PAGE_OFFSET, %edi
> 


  parent reply	other threads:[~2009-03-16 19:49 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-14 23:43 Latest brk patchset H. Peter Anvin
2009-03-15  0:32 ` Jeremy Fitzhardinge
2009-03-15  0:37   ` H. Peter Anvin
2009-03-15  6:09     ` Jeremy Fitzhardinge
2009-03-15  6:29     ` Jeremy Fitzhardinge
2009-03-15 20:38       ` [crash] " Ingo Molnar
2009-03-15 20:42         ` Ingo Molnar
2009-03-15 21:19         ` Jeremy Fitzhardinge
2009-03-15 21:28           ` Ingo Molnar
2009-03-15 23:28             ` Jeremy Fitzhardinge
2009-03-16  8:54               ` Ingo Molnar
2009-03-16 16:12                 ` Jeremy Fitzhardinge
2009-03-16 16:56                   ` Yinghai Lu
2009-03-16 17:20                     ` Jeremy Fitzhardinge
2009-03-16 17:54                     ` Jeremy Fitzhardinge
2009-03-16 18:15                       ` H. Peter Anvin
2009-03-16 18:17                       ` Yinghai Lu
2009-03-16 18:22                         ` H. Peter Anvin
2009-03-16 18:31                           ` Yinghai Lu
2009-03-16 18:17                       ` H. Peter Anvin
2009-03-16 19:25                         ` Jeremy Fitzhardinge
2009-03-16 19:34                           ` H. Peter Anvin
2009-03-16 19:48                           ` Yinghai Lu [this message]
2009-03-16 20:00                             ` Jeremy Fitzhardinge
2009-03-16 20:26                               ` H. Peter Anvin
2009-03-16 20:59                                 ` Jeremy Fitzhardinge
2009-03-16 21:14                                   ` H. Peter Anvin
2009-03-16 21:31                                     ` Jeremy Fitzhardinge
2009-03-16 22:35                                       ` H. Peter Anvin
2009-03-17  2:26                                         ` Yinghai Lu
2009-03-17  4:00                                           ` H. Peter Anvin
2009-03-17  5:07                                             ` Jeremy Fitzhardinge
2009-03-17 16:04                                               ` H. Peter Anvin
2009-03-17 19:42                                                 ` Jeremy Fitzhardinge
2009-03-17 19:45                                                   ` H. Peter Anvin
2009-03-17 19:59                                                     ` Jeremy Fitzhardinge
2009-03-17 21:19                                                       ` Yinghai Lu
2009-03-17 21:28                                                         ` Jeremy Fitzhardinge
2009-03-17 19:47                                                 ` Jeremy Fitzhardinge
2009-03-22 15:09                 ` Ingo Molnar
2009-03-22 17:12                   ` Jeremy Fitzhardinge
2009-03-22 17:22                     ` Ingo Molnar
2009-03-22 21:48                       ` Jeremy Fitzhardinge
2009-03-23 16:39                         ` [tip:x86/setup] x86/dmi: fix dmi_alloc() section mismatches Jeremy Fitzhardinge
2009-03-15  1:37   ` Latest brk patchset H. Peter Anvin
2009-03-15  4:43     ` Yinghai Lu
2009-03-15  4:51       ` H. Peter Anvin
2009-03-15  5:33         ` Yinghai Lu
2009-03-15  6:05           ` Jeremy Fitzhardinge
2009-03-15  6:25             ` Yinghai Lu
2009-03-15  6:03     ` Jeremy Fitzhardinge

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=49BEAD27.3050801@kernel.org \
    --to=yinghai@kernel.org \
    --cc=hpa@zytor.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.