Re: [BUG] Lockdep recursive locking in kmem_cache_free

[Alok Kataria <alok.kataria@calsoftinc.com>]

On Fri, 2006-07-28 at 14:26 -0700, Christoph Lameter wrote:
> On Fri, 28 Jul 2006, Ravikiran G Thirumalai wrote:
> 
> > Why should there be any problem taking the remote l3 lock?  If the remote
> > node does not have cpu that does not mean we cannot take a lock from the
> > local node!!! 
> > 
> > I think current git does not teach lockdep to ignore recursion for
> > array_cache->lock when the array_cache->lock are from different cases.  As
> > Arjan pointed out, I can see that l3->list_lock is special cased, but I
> > cannot find where array_cache->lock is taken care of.
> 
> Ok.
>  
> > Again, if this is indeed a problem (recursion) machine should not boot even,
> > when compiled without lockdep, tglx, can you please verify this?
> 
> We seem to be fine on that level.
> 
> I would still like to see someone thinking through this a bit more.
> 
> Allocations via page_alloc_node() may be redirected by cpusets and 
> because nodes are low on memory. This means that we get memory on a 
> different node than we requested. How does that impact the alien lock 
> situation? 

Good point, i saw this thing occur with 2.6.17 tree (objects coming from
different node than requested), but in no ways does that affect the
correctness of the system. But i saw a marginal performance drop with
this case. 

As far as figuring out if the object is from a remote node we check the
node id from the slab, which was intialised while allocating the slab.
So the slab layer now just knows that objects in this slab are from the
slab->nodeid node, irrespective of the node from where the actual page
came. 

Thus nothing goes wrong, but we may see a little performance drop.


> In particular what happens if the off slab allocation for 
> the management object was on a different node from the slab data?

Same thing performance drop.

Thanks & Regards,
Alok