Re: 2.6.14-rc1-git-now still dying in mm/slab - this time line 1849

[Petr Vandrovec <vandrove@vc.cvut.cz>]

Andrew Morton wrote:
> Christoph Lameter <clameter@engr.sgi.com> wrote:
> 
>>On Wed, 21 Sep 2005, Christoph Lameter wrote:
>>
>> > Hmm. This likely has something to do with debugging code. I was unable to 
>> > reproduce this on amd64 with your config. I get another failure with 
>> > 2.6.14-rc2 on ia64 if I enable all the debugging features that you have. 
>> > The system works fine if no debugging is configured:
>> > 
>> > kernel BUG at kernel/workqueue.c:541!
>> > swapper[1]: bugcheck! 0 [1]
>>
>> I fixed the above issue (a structure became larger than the maximum 
>> allowed by the slab allocator) and the kernel boots fine now on an 8 way 
>> ia64. Cannot reproduce the problem.
> 
> 
> Petr can.  I think we're still waiting for him to test the below (please):

Sorry, I've missed that half of email completely.  Yes, it seems to fix problem,
box has currently 8 min uptime, which is 7:55 more than it survived before.
							Thanks,
								Petr Vandrovec

> Could you try the following patch:
> 
> ---
> 
> The numa slab allocator may allocate pages from foreign nodes onto the lists
> for a particular node if a node runs out of memory. Inspecting the slab->nodeid
> field will not reflect that the page is now in use for the slabs of another node.
> 
> This patch fixes that issue by adding a node field to free_block so that the caller
> can indicate which node currently uses a slab.
> 
> Also removes the check for the current node from kmalloc_cache_node since the
> process may shift later to another node which may lead to an allocation on another
> node than intended.
> 
> Signed-off-by: Christoph Lameter <clameter@sgi.com>