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