Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762002AbXKCUD4 (ORCPT ); Sat, 3 Nov 2007 16:03:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758226AbXKCUDs (ORCPT ); Sat, 3 Nov 2007 16:03:48 -0400 Received: from extu-mxob-2.symantec.com ([216.10.194.135]:39162 "EHLO extu-mxob-2.symantec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757155AbXKCUDr (ORCPT ); Sat, 3 Nov 2007 16:03:47 -0400 Date: Sat, 3 Nov 2007 20:03:19 +0000 (GMT) From: Hugh Dickins X-X-Sender: hugh@blonde.wat.veritas.com To: Christoph Lameter cc: Linus Torvalds , Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] slub: fix Objects count In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1842 Lines: 56 On Sat, 3 Nov 2007, Christoph Lameter wrote: > On Sat, 3 Nov 2007, Hugh Dickins wrote: > > > I was afraid you might say something like that. > > Perhaps it'll be a patch I need to use in my own builds. > > Though I'd have thought others would want that accuracy too. > > Didn't SLAB give it? (The "r*gr*ss**n" word!) > > Slab also only counts objects that are not in the queues. See free_block() > f.e. I'll take your word for it, and apologize for my slur on slub! (Slub has a great deal to admire in it, I should say.) > > We could improve the situation by flushing all cpu slabs before counts are > determined. > > Which can be done manually. Run > > slabinfo -s > > and then look at the numbers. Mmm, I'd been doing slabinfo -v sometimes. These are fine in some situations, but it's always better when the observer can avoid interfering with the observed. Impossible, we know, but... Also, many caches too quickly re-equip themselves with cpu slabs which again obscure the numbers. > > > Adds to much overhead to the fast paths > > > > You've come to that conclusion very quickly! > > I have just spend a few weeks optimizing the fast and slow paths and there > is some additional overhead that I am still trying to eliminate. > > > Any numbers to back it up? > > The performance in the fast paths depends on updating only a single word > for an allocation. Adding another counter makes that impossible. Gosh, that's a tighter corner than any I've been in. > > See the recent post on SLUB regression on SMP. I'll have to read up on that, thanks for the pointer. Hugh - 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/