From: Lucio Correia <ljhc@br.ibm.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: linux-kernel@vger.kernel.org, Arnd Bergmann <arndb@arndb.de>
Subject: Re: SLUB doesn't work with kdump kernel on Cell
Date: Tue, 14 Aug 2007 12:43:59 -0300 [thread overview]
Message-ID: <1187106239.3298.2.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0708081321400.14478@schroedinger.engr.sgi.com>
On Wed, 2007-08-08 at 13:26 -0700, Christoph Lameter wrote:
> On Wed, 8 Aug 2007, Lucio Correia wrote:
>
> > Hi Christoph,
> >
> > I found a problem with SLUB when trying to boot a kdump kernel on a Cell
> > QS20 Blade running Fedora 7, kernel 2.6.22.5. If I use SLAB for the
> > kdump kernel, everything works ok. The fact is that SLUB doesn't find a
> > page frame for allocation in the current node, due to the flag
> > GFP_THISNODE on a call to new_slab, and stops at a BUG_ON on line 1802
> > of slub.c.
>
> This is due to the node 1 having only one page. Could you just switch node
> 1 off?
>
> SLAB boots because it falls back to node 0 for the control structures. So
> it creates useless control structures for node 1. These are then never
> used since any allocation attempt to node 1 falls back to node 0.
Hi Christoph,
Shouldn't SLUB falls back to other node also for the case it can't
allocate memory?
>
> > I understand that this flag should not be removed, and that there is a
> > better solution, but it demonstrates the problem. Could you give me some
> > direction on the better way to solve this problem?
>
> Do not create a node that just has one page in it?
>
> Or make it truly empty? An empty node will cause GFP_THISNODE to fall back
> and you then have the same useless control structure allocation as on
> SLAB.
--
Lucio Correia
Software Engineer
IBM LTC Brazil
next prev parent reply other threads:[~2007-08-14 15:43 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-08 20:15 SLUB doesn't work with kdump kernel on Cell Lucio Correia
2007-08-08 20:26 ` Christoph Lameter
2007-08-08 20:34 ` Arnd Bergmann
2007-08-08 20:39 ` Christoph Lameter
2007-08-14 15:43 ` Lucio Correia [this message]
2007-08-14 19:42 ` Christoph Lameter
2007-08-15 0:57 ` Michael Ellerman
2007-08-15 1:56 ` Christoph Lameter
2007-08-15 2:11 ` Christoph Lameter
2007-08-15 19:57 ` Lucio Correia
2007-08-15 20:21 ` Christoph Lameter
2007-08-08 21:10 ` Arnd Bergmann
2007-08-09 13:57 ` Lucio Correia
2007-08-10 0:34 ` Michael Ellerman
2007-08-10 15:43 ` [Cbe-oss-dev] " Arnd Bergmann
2007-08-10 0:26 ` Michael Ellerman
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=1187106239.3298.2.camel@localhost.localdomain \
--to=ljhc@br.ibm.com \
--cc=arndb@arndb.de \
--cc=clameter@sgi.com \
--cc=linux-kernel@vger.kernel.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.