Re: [PATCH 2/2] slub: continue to seek slab in node partial if met a null page

["Alex,Shi" <alex.shi@intel.com>]

On Wed, 2011-09-07 at 23:01 +0800, Christoph Lameter wrote:
> On Wed, 7 Sep 2011, Alex,Shi wrote:
> 
> > In the per cpu partial slub, we may add a full page into node partial
> > list. like the following scenario:
> >
> > 	cpu1     		        	cpu2
> >     in unfreeze_partials	           in __slab_alloc
> > 	...
> >    add_partial(n, page, 1);
> > 					alloced from cpu partial, and
> > 					set frozen = 1.
> >    second cmpxchg_double_slab()
> >    set frozen = 0
> 
> This scenario cannot happen as the frozen state confers ownership to a
> cpu (like the cpu slabs). The cpu partial lists are different from the per
> node partial lists and a slab on the per node partial lists should never
> have the frozen bit set.

oh, sorry, I am wrong here. 
Firstly, since unfreeze_partials only drain self cpu partial slabs, and
__slab_alloc also only check self cpu partial. So, above scenario won't
happen.  
Secondly, add_partial mean got the node list_lock already, so if
__slab_alloc try to alloc from the node partial, it won't get the
list_lock before cmpxchg finished. 

> 
> > If it happen, we'd better to skip the full page and to seek next slab in
> > node partial instead of jump to other nodes.
> 
> But I agree that the patch can be beneficial if acquire slab ever returns
> a full page. That should not happen though. Is this theoretical or do you
> have actual tests that show that this occurs?

I didn't find a real case for this now. So, do you still like to pick up
this as a defense for future more lockless usage? 



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>