From: Andrew Morton <akpm@digeo.com>
To: "Martin J. Bligh" <mbligh@aracnet.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: New panic (io-apic / timer?) going from 2.5.44 to 2.5.44-mm1
Date: Tue, 22 Oct 2002 17:31:43 -0700 [thread overview]
Message-ID: <3DB5EDEF.59A27A9A@digeo.com> (raw)
In-Reply-To: 442050000.1035332459@flay
"Martin J. Bligh" wrote:
>
> >> Hmmm ... 2.5.43-mm2 and 2.5.44 work fine, but 2.5.44-mm1 (and mm2)
> >> panic consistently on boot for a 16 way NUMA-Q.
> >>
> >> Normally this box will boot with TSC on or off. If anyone has any pointers as
> >> to what's changed in the mm patchset going from 43-mm2 to 44-mm1 that
> >> might have touched this area (I can't see anything), please poke me in the
> >> eye. Otherwise I'll just keep digging into it ....
> >>
> >
> >
> > Is possibly the code which defers the allocation of the per-cpu
> > memory until the secondary processors are being brought online.
>
> Aha ... ;-) thanks for the pointer. Will poke at that.
The kgdb code plays around at that level too. A patch -R of
kgdb.patch would be interesting.
> > I've decided to toss that. It's causing some grief for architectures,
> > and only buys us 10k * (NR_CPUS - nr-cpus) worth of memory anyway.
>
> Hmmm ... I guess people with SMP normally have lots of RAM anyway,
> and those few that care could just config NR_CPUS down. Shame though,
> automagical is much nicer. Maybe we can work out exactly why it's broken
> instead.
>
> > Well. It would be useful for NUMA to be able to place the per-cpu storage
> > into node-local memory. But the code doesn't do that. It just uses
> > kmalloc on the boot cpu, and we don't have an alloc_pages_for_another_cpu()
> > API..
>
> Well at a page granularity level you have alloc_pages_node(cpu_to_node).
> I suppose technically that's not guaranteed, but on boot it'll never fall back.
> If you need it in permanent KVA, you can remap it into the vmalloc reserve
> area.
That would suit.
> Why do you need to do it that late, should be able to do it once you've parsed
> mptables? alloc_bootmem / alloc_bootmem_node ?
Lack of architecture hooks, maybe? That'd be one for Rusty.
next prev parent reply other threads:[~2002-10-23 0:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-22 23:52 New panic (io-apic / timer?) going from 2.5.44 to 2.5.44-mm1 Martin J. Bligh
2002-10-23 0:10 ` Andrew Morton
2002-10-23 0:20 ` Martin J. Bligh
2002-10-23 0:31 ` Andrew Morton [this message]
2002-10-23 5:57 ` Martin J. Bligh
2002-10-23 6:42 ` Martin J. Bligh
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=3DB5EDEF.59A27A9A@digeo.com \
--to=akpm@digeo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@aracnet.com \
/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