Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757401AbYJWQsm (ORCPT ); Thu, 23 Oct 2008 12:48:42 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754322AbYJWQsa (ORCPT ); Thu, 23 Oct 2008 12:48:30 -0400 Received: from nlpi025.sbcis.sbc.com ([207.115.36.54]:46153 "EHLO nlpi025.prodigy.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753467AbYJWQs3 (ORCPT ); Thu, 23 Oct 2008 12:48:29 -0400 Date: Thu, 23 Oct 2008 11:47:48 -0500 (CDT) From: Christoph Lameter X-X-Sender: cl@quilx.com To: Eric Dumazet 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 Subject: Re: SLUB defrag pull request? In-Reply-To: <4900A7C8.9020707@cosmosbay.com> Message-ID: 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> <4900A7C8.9020707@cosmosbay.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.5 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1365 Lines: 39 On Thu, 23 Oct 2008, Eric Dumazet wrote: >> SLUB touches objects by default when allocating. And it does it immediately >> in slab_alloc() in order to retrieve the pointer to the next object. So >> there is no point of hinting there right now. >> > > 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 transactions, > acquiring > the cache line in an exclusive way instead of shared one. Most architectures actually can do that. Its probably worth to run some tests with that. Conversion of a cacheline from shared to exclusive can cost something. >> If we go to the pointer arrays then the situation is similar to SLAB where >> the object is not touched by the allocator. Then the hint would be useful >> again. > > It is usefull right now for ((SLAB_DESTROY_BY_RCU | SLAB_POISON) or ctor > caches. Correct. > Probably not that important because many objects are very large anyway, and a > prefetchw() > of the begining of object is partial. Right. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/