From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Zhang, Yanmin" Subject: Re: [patch 21/21] slab defrag: Obsolete SLAB Date: Thu, 15 May 2008 11:26:42 +0800 Message-ID: <1210822002.3177.121.camel@ymzhang> References: <20080510030831.796641881@sgi.com> <20080510030919.604216074@sgi.com> <4825709A.2020407@firstfloor.org> <20080510221515.3540a6cc@bree.surriel.com> <2f11576a0805120038s334dc56cuaf16b8b7c6f87098@mail.gmail.com> <84144f020805120054t1370236ei5ff52279457e026e@mail.gmail.com> <482B2617.5010605@firstfloor.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Andi Kleen , Pekka Enberg , KOSAKI Motohiro , Rik van Riel , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Mel Gorman , mpm@selenic.com, Matthew Wilcox To: Christoph Lameter Return-path: Received: from mga06.intel.com ([134.134.136.21]:10434 "EHLO orsmga101.jf.intel.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751215AbYEOD3c (ORCPT ); Wed, 14 May 2008 23:29:32 -0400 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, 2008-05-14 at 11:03 -0700, Christoph Lameter wrote: > On Wed, 14 May 2008, Andi Kleen wrote: >=20 > > iirc profiling analysis showed that the problem was the page lock > > serialization (in particular the slab_lock() in __slab_free). That > > was on 2.6.24.2 >=20 > Do you have an URL? >=20 > > I think the problem is that this atomic operation thrashes cache li= nes > > around. Really counting cycles on instructions is not that interest= ing, > > but minimizing the cache thrashing is. And for that it looks like s= lub > > is worse. >=20 > It can thrash cachelines if objects from the same slab page are freed= =20 > simultaneously on multiple processors. That occurred in the hackbench= =20 > regression that we addressed with the dynamic configuration of slab s= izes. hackbench regression is because of slow allocation instead of slow free= ing. With =EF=BB=BFdynamic configuration of slab sizes, fast allocation beco= mes 97% (the bad one is 68%), but fast free is always 8~9% with/without the patch. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html