On Fri, Sep 7, 2012 at 2:31 PM, <[email protected]> wrote:
>
> The patch titled
> Subject: x86/mm: limit extra padding calculation to x86_32
> has been added to the -mm tree. Its filename is
> x86-mm-limit-2-4m-size-calculation-to-x86_32.patch
>
> Before you just go and hit "reply", please:
> a) Consider who else should be cc'ed
> b) Prefer to cc a suitable mailing list as well
> c) Ideally: find the original patch on the mailing list and do a
> reply-to-all to that, adding suitable additional cc's
>
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
> The -mm tree is included into linux-next and is updated
> there every 3-4 working days
>
> ------------------------------------------------------
> From: Stefan Bader <[email protected]>
> Subject: x86/mm: limit extra padding calculation to x86_32
>
> Starting with kernel v3.5 kexec based crash dumping was observed to fail
> (without any apparent message) on x86_64 machines. This was traced to a
> lack of memory triggered by a substantial increase (several megabyes) in
> the size of the initial page tables.
>
> After regression (on a VM with 2GB of memory):
> kernel direct mapping tables up to 0x7fffcfff @ [mem 0x1fbfd000-0x1fffffff]
> size = 4206591 bytes
>
> With this patch applied:
> kernel direct mapping tables up to 0x7fffcfff @ [mem 0x1fffc000-0x1fffffff]
> size = 16383 bytes
>
> A bisection lead to commit 722bc6b ("x86/mm: Fix the size calculation of
> mapping tables")
>
> This change modified the extra space calculation to take into account that
> the first 2/4M range of memory would be mapped as 4K pages as suggested in
> chapter 11.11.9 of the Intel software developer's manual.
>
> However this is currently only true for x86_32 (the reasons behind that
> are unclear but apparently the whole page table setup needs to be re-
> visited as it turns out to be very easy to break and has flaws in its
> current form).
>
> Until the logic can be revisited and combined, pair up the extra space
> calculation with the logic which creates the extra mappings.
>
> Signed-off-by: Stefan Bader <[email protected]>
> Cc: WANG Cong <[email protected]>
> Cc: Yinghai Lu <[email protected]>
> Cc: Tejun Heo <[email protected]>
> Cc: <[email protected]> [v3.5+]
> Cc: Ingo Molnar <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: "H. Peter Anvin" <[email protected]>
> Signed-off-by: Andrew Morton <[email protected]>
> ---
>
> arch/x86/mm/init.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff -puN arch/x86/mm/init.c~x86-mm-limit-2-4m-size-calculation-to-x86_32
> arch/x86/mm/init.c
> --- a/arch/x86/mm/init.c~x86-mm-limit-2-4m-size-calculation-to-x86_32
> +++ a/arch/x86/mm/init.c
> @@ -60,10 +60,11 @@ static void __init find_early_table_spac
> extra = end - ((end>>PMD_SHIFT) << PMD_SHIFT);
> #ifdef CONFIG_X86_32
> extra += PMD_SIZE;
> -#endif
> +
> /* The first 2/4M doesn't use large pages. */
> if (mr->start < PMD_SIZE)
> extra += mr->end - mr->start;
> +#endif
>
> ptes = (extra + PAGE_SIZE - 1) >> PAGE_SHIFT;
> } else
> _
>
> Patches currently in -mm which might be from [email protected] are
>
> x86-mm-limit-2-4m-size-calculation-to-x86_32.patch
>
three lines
/* The first 2/4M doesn't use large pages. */
if (mr->start < PMD_SIZE)
extra += mr->end - mr->start;
should be just dropped even for 32 bit.
Thanks
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
