From: Andy Whitcroft <apw@shadowen.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Greg KH <greg@kroah.com>, Dave Jones <davej@redhat.com>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Martin Ebourne <fedora@ebourne.me.uk>,
Zou Nan hai <nanhai.zou@intel.com>,
Suresh Siddha <suresh.b.siddha@intel.com>,
Andi Kleen <ak@suse.de>,
stable@kernel.org, Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <clameter@sgi.com>, Mel Gorman <mel@csn.ul.ie>
Subject: Re: [stable] 2.6.23 boot failures on x86-64.
Date: Mon, 29 Oct 2007 20:23:11 +0000 [thread overview]
Message-ID: <20071029202311.GO5529@shadowen.org> (raw)
In-Reply-To: <alpine.LFD.0.999.0710291123200.30120@woody.linux-foundation.org>
On Mon, Oct 29, 2007 at 11:37:40AM -0700, Linus Torvalds wrote:
>
>
> On Mon, 29 Oct 2007, Greg KH wrote:
> >
> > I'll be glad to revert it in -stable, if it's also reverted in Linus's
> > tree first :)
>
> We've had some changes since 2.6.23, and afaik, the
> "alloc_bootmem_high_node()" code is alreadt effectively dead there. It's
> only called if CONFIG_SPARSEMEM_VMEMMAP is *not* enabled, and I *think* we
> enable it by force on x86-64 these days.
CONFIG_SPARSEMEM_VMEMMAP is the default when SPARSEMEM is enabled
on x86_64. The overall default remains DISCONTIGMEM, mainly as a
safety measure while the i386/x86_64 => x86 merge stablises. But yes
this code is only used when SPARSEMEM is enabled but VMEMMAP is not.
So it is effectivly redundant.
> More people added to Cc, just to clarify whether I'm just confused.
>
> Andy, Christoph, Mel: commit 2e1c49db4c640b35df13889b86b9d62215ade4b6 aka
> "x86_64: allocate sparsemem memmap above 4G" is the one that causes the
> failures, just fyi.
That patch seems to have a laudable goal of trying to push the memory
which backs the sparsemem memmap out to non-dma memory. I would have
expected that call to actually succeed as the bootmem allocator seems to
try at the goal which would likely be outside the node on a small
machine, and then retry without a goal. Which is what the code without
the goal does. Most illogical.
> Martin - it would be great if you could try out your failing machine with
> 2.6.24-rc1 (or a nightly snapshot or current git.. the more recent the
> better).
>
> But if I'm right, that commit should be reverted from 2.6.24 just because
> it's pointless (even if the bug itself is gone). And if I'm wrong, it
> should be reverted. So something like the appended would make sense
> regardless.
>
> Can I get a "tested-by"? And/or ack/nack's on my half-arsed theory above?
This code is definatly only used when SPARSEMEM is enabled, and VMEMMAP
is not which is not a combination we see on x86_64.
Acked-by: Andy Whitcroft <apw@shadowen.org>
> Linus
> --
> From: Linus Torvalds <torvalds@woody.linux-foundation.org>
>
> Revert "x86_64: allocate sparsemem memmap above 4G"
>
> This reverts commit 2e1c49db4c640b35df13889b86b9d62215ade4b6, since
> testing in Fedora has shown it to cause boot failures, as per Dave
> Jones. Bisected down by Martin Ebourne.
>
> Cc: Dave Jones <davej@redhat.com>
> Cc: Martin Ebourne <fedora@ebourne.me.uk>
> Cc: Zou Nan hai <nanhai.zou@intel.com>
> Cc: Suresh Siddha <suresh.b.siddha@intel.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index 1e3862e..a7308b2 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -728,12 +728,6 @@ int in_gate_area_no_task(unsigned long addr)
> return (addr >= VSYSCALL_START) && (addr < VSYSCALL_END);
> }
>
> -void * __init alloc_bootmem_high_node(pg_data_t *pgdat, unsigned long size)
> -{
> - return __alloc_bootmem_core(pgdat->bdata, size,
> - SMP_CACHE_BYTES, (4UL*1024*1024*1024), 0);
> -}
> -
> const char *arch_vma_name(struct vm_area_struct *vma)
> {
> if (vma->vm_mm && vma->vm_start == (long)vma->vm_mm->context.vdso)
> diff --git a/include/linux/bootmem.h b/include/linux/bootmem.h
> index c83534e..0365ec9 100644
> --- a/include/linux/bootmem.h
> +++ b/include/linux/bootmem.h
> @@ -59,7 +59,6 @@ extern void *__alloc_bootmem_core(struct bootmem_data *bdata,
> unsigned long align,
> unsigned long goal,
> unsigned long limit);
> -extern void *alloc_bootmem_high_node(pg_data_t *pgdat, unsigned long size);
>
> #ifndef CONFIG_HAVE_ARCH_BOOTMEM_NODE
> extern void reserve_bootmem(unsigned long addr, unsigned long size);
> diff --git a/mm/sparse.c b/mm/sparse.c
> index 08fb14f..e06f514 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -220,12 +220,6 @@ static int __meminit sparse_init_one_section(struct mem_section *ms,
> return 1;
> }
>
> -__attribute__((weak)) __init
> -void *alloc_bootmem_high_node(pg_data_t *pgdat, unsigned long size)
> -{
> - return NULL;
> -}
> -
> static unsigned long usemap_size(void)
> {
> unsigned long size_bytes;
> @@ -267,11 +261,6 @@ struct page __init *sparse_mem_map_populate(unsigned long pnum, int nid)
> if (map)
> return map;
>
> - map = alloc_bootmem_high_node(NODE_DATA(nid),
> - sizeof(struct page) * PAGES_PER_SECTION);
> - if (map)
> - return map;
> -
> map = alloc_bootmem_node(NODE_DATA(nid),
> sizeof(struct page) * PAGES_PER_SECTION);
> return map;
-apw
next prev parent reply other threads:[~2007-10-29 20:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-29 17:50 2.6.23 boot failures on x86-64 Dave Jones
2007-10-29 18:07 ` [stable] " Greg KH
2007-10-29 18:37 ` Linus Torvalds
2007-10-29 19:51 ` Christoph Lameter
2007-10-29 19:52 ` Siddha, Suresh B
2007-10-29 20:09 ` Christoph Lameter
2007-10-29 20:23 ` Andy Whitcroft [this message]
2007-10-29 20:27 ` Martin Ebourne
2007-10-29 18:18 ` Andi Kleen
2007-10-29 18:47 ` Dave Jones
2007-10-29 19:03 ` Andi Kleen
2007-10-29 19:43 ` Dave Jones
2007-10-29 19:56 ` Andi Kleen
2007-10-29 21:21 ` Martin Ebourne
2007-10-31 6:04 ` Zou Nan hai
2007-10-31 6:19 ` Zou Nan hai
2007-10-29 20:06 ` Dave Jones
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=20071029202311.GO5529@shadowen.org \
--to=apw@shadowen.org \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=davej@redhat.com \
--cc=fedora@ebourne.me.uk \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mel@csn.ul.ie \
--cc=nanhai.zou@intel.com \
--cc=stable@kernel.org \
--cc=suresh.b.siddha@intel.com \
--cc=torvalds@linux-foundation.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