On Wednesday 08 August 2007, Christoph Lameter wrote:
>
> > 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?
the kdump kernel needs to access data on the SPUs on node 1. It might be
possible to change that so we can access the SPUs even if there is only
one node, but it's probably not easy to do.
In the future, we also may have configurations where we need to run with
memoryless nodes on a production environment, so it should really just
work.
> > 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.
What makes you assume that there is one page in the node? AFAICS, it
is a CPU-only node already without any pages.
Arnd <><
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
