lkml.org 
[lkml]   [2008]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: crash in kmem_cache_init
On Tue, 22 Jan 2008, Mel Gorman wrote:

> Christoph/Pekka, this patch is papering over the problem and something
> more fundamental may be going wrong. The crash occurs because l3 is NULL
> and the cache is kmem_cache so this is early in the boot process. It is
> selecting l3 based on node 2 which is correct in terms of available memory
> but it initialises the lists on node 0 because that is the node the CPUs are
> located. Hence later it uses an uninitialised nodelists and BLAM. Relevant
> parts of the log for seeing the memoryless nodes in relation to CPUs is;

Would it be possible to run the bootstrap on a cpu that has a
node with memory associated to it? I believe we had the same situation
last year when GFP_THISNODE was introduced?

After you reverted the slab memoryless node patch there should be per node
structures created for node 0 unless the node is marked offline. Is it? If
so then you are booting a cpu that is associated with an offline node.

> Can you see a better solution than this?

Well this means that bootstrap will work by introducing foreign objects
into the per cpu queue (should only hold per cpu objects). They will
later be consumed and then the queues will contain the right objects so
the effect of the patch is minimal.

I thought we fixed the similar situation last year by dropping
GFP_THISNODE for some allocations?


\
 
 \ /
  Last update: 2008-01-22 21:13    [W:1.487 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site