Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754226AbXLVMgS (ORCPT ); Sat, 22 Dec 2007 07:36:18 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750959AbXLVMgL (ORCPT ); Sat, 22 Dec 2007 07:36:11 -0500 Received: from one.firstfloor.org ([213.235.205.2]:43232 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750779AbXLVMgK (ORCPT ); Sat, 22 Dec 2007 07:36:10 -0500 Date: Sat, 22 Dec 2007 13:37:05 +0100 From: Andi Kleen To: Ingo Molnar Cc: Andi Kleen , Christoph Lameter , Peter Zijlstra , Linus Torvalds , Steven Rostedt , LKML , Andrew Morton , Christoph Hellwig , "Rafael J. Wysocki" Subject: Re: Major regression on hackbench with SLUB (more numbers) Message-ID: <20071222123705.GA14767@one.firstfloor.org> References: <20071221120908.GA15926@elte.hu> <1198275391.30889.3.camel@lappy> <1198275453.30889.4.camel@lappy> <20071221225413.GA26189@elte.hu> <20071222100326.GF26157@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071222100326.GF26157@elte.hu> User-Agent: Mutt/1.4.2.1i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1540 Lines: 37 > could be offered on SLUB too. Sure (I argued that in a earlier mail in fact), but it doesn't make sense to fake into the old slabinfo format. > > 'top' isnt critical functionality either like udev, and the ABI does not > only cover 'critical' functionality. A utility suddenly not working > gives Linux a pretty amateurish feeling. Should we tell users/admins: > "Hehe, gotcha! Didnt you know /proc/slabinfo was not an ABI? Poor sob. > If you want your stuff to continue working, use Windows next time around > or what. Sheesh, what do these people want!' ;-) While I sympatise with this point in practice non critial ABIs change regularly (and sometimes even critical ones like sched_yield ...) > > the rule is very simple: unless you have really, really, really, REALLY > good reasons, just dont break stuff. Removing an interface that exposes lots of internal details when you rewrite the subsystem and those internal details all change seems like a good reason to me. Besides the original interface was broken anyways. The version number was one of the interface worst ideas ever imho and slabtop's handling of it quite dumb. The better way would have been to always add new fields and never remove old ones. Hopefully the new /sys based interface will be better. -Andi -- 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/