From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 29 Feb 2008 14:01:20 +0000 (GMT) From: Hugh Dickins Subject: Re: [patch 05/10] slub: Remove slub_nomerge In-Reply-To: <20080229043552.282285411@sgi.com> Message-ID: References: <20080229043401.900481416@sgi.com> <20080229043552.282285411@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Christoph Lameter Cc: Pekka Enberg , Matt Mackall , linux-mm@kvack.org List-ID: On Thu, 28 Feb 2008, Christoph Lameter wrote: > No one has used that option for a long time and AFAICT its currently utterly > useless. Not so at all. I certainly use it: not often, but from time to time, in debugging. If you're narrowing down on something, it's a worthwhile tool to separate the different uses of a particular size. And when studying slabinfo numbers, perhaps for a leak e.g. why doesn't slabinfo doesn't show vm_area_struct, oh, it's sharing :0000088 with cfq_queue, so we need slub_nomerge to see their actual numbers. Perhaps I'm missing something: how does everyone else get the right numbers without slub_nomerge? Admittedly it's often too blunt an instrument for debugging: I'd be happier with a debug flag which has no other side-effect than nomerge (all the other SLUB_NEVER_MERGE flags seemed to have side-effects that I wanted to avoid when trying to reproduce an elusive corruption), that can be applied to a single cache as well as to the whole lot. I could add that if you don't (or I could hack my mm/slub.c when I need to, that's always an option: but I do think nomerge can be useful out in the field). If you go ahead and remove slub_nomerge, please also remove it from Documentation/kernel-parameters.txt. Hugh -- 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/ . Don't email: email@kvack.org