From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: SLUB defrag pull request? Date: Thu, 23 Oct 2008 18:35:20 +0200 Message-ID: <4900A7C8.9020707@cosmosbay.com> References: <1223883004.31587.15.camel@penberg-laptop> <84144f020810221348j536f0d84vca039ff32676e2cc@mail.gmail.com> <1224745831.25814.21.camel@penberg-laptop> <84144f020810230658o7c6b3651k2d671aab09aa71fb@mail.gmail.com> <84144f020810230714g7f5d36bas812ad691140ee453@mail.gmail.com> <49009575.60004@cosmosbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Pekka Enberg , Miklos Szeredi , nickpiggin@yahoo.com.au, hugh@veritas.com, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org To: Christoph Lameter Return-path: Received: from smtp2e.orange.fr ([80.12.242.113]:45168 "EHLO smtp2e.orange.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754182AbYJWQjP convert rfc822-to-8bit (ORCPT ); Thu, 23 Oct 2008 12:39:15 -0400 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Christoph Lameter a =E9crit : > On Thu, 23 Oct 2008, Eric Dumazet wrote: >=20 >> At alloc time, I remember I added a prefetchw() call in SLAB in=20 >> __cache_alloc(), >> this could explain some differences between SLUB and SLAB too, since= SLAB >> gives a hint to processor to warm its cache. >=20 > SLUB touches objects by default when allocating. And it does it=20 > immediately in slab_alloc() in order to retrieve the pointer to the n= ext=20 > object. So there is no point of hinting there right now. >=20 Please note SLUB touches by reading object. prefetchw() gives a hint to cpu saying this cache line is going to be *= modified*, even if first access is a read. Some architectures can save some bus transac= tions, acquiring the cache line in an exclusive way instead of shared one. > If we go to the pointer arrays then the situation is similar to SLAB=20 > where the object is not touched by the allocator. Then the hint would= be=20 > useful again. It is usefull right now for ((SLAB_DESTROY_BY_RCU | SLAB_POISON) or cto= r caches. Probably not that important because many objects are very large anyway,= and a prefetchw() of the begining of object is partial. -- 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