From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail6.bemta12.messagelabs.com (mail6.bemta12.messagelabs.com [216.82.250.247]) by kanga.kvack.org (Postfix) with ESMTP id 8DFB76B016A for ; Wed, 7 Sep 2011 11:01:25 -0400 (EDT) Date: Wed, 7 Sep 2011 10:01:22 -0500 (CDT) From: Christoph Lameter Subject: Re: [PATCH 2/2] slub: continue to seek slab in node partial if met a null page In-Reply-To: <1315363526.31737.164.camel@debian> Message-ID: References: <1315188460.31737.5.camel@debian> <1315357399.31737.49.camel@debian> <1315362396.31737.151.camel@debian> <1315363526.31737.164.camel@debian> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: "Alex,Shi" Cc: "penberg@kernel.org" , "akpm@linux-foundation.org" , linux-mm@kvack.org, Andi Kleen 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. > 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? -- 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: email@kvack.org