From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964977AbWD0Il5 (ORCPT ); Thu, 27 Apr 2006 04:41:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964980AbWD0Il5 (ORCPT ); Thu, 27 Apr 2006 04:41:57 -0400 Received: from pentafluge.infradead.org ([213.146.154.40]:48528 "EHLO pentafluge.infradead.org") by vger.kernel.org with ESMTP id S964977AbWD0Il4 (ORCPT ); Thu, 27 Apr 2006 04:41:56 -0400 Subject: Re: [PATCH] likely cleanup: remove unlikely for kfree(NULL) From: Arjan van de Ven To: Adrian Bunk Cc: Pekka J Enberg , Nick Piggin , =?ISO-8859-1?Q?J=F6rn?= Engel , Hua Zhong , linux-kernel@vger.kernel.org, akpm@osdl.org In-Reply-To: <20060427083157.GD3570@stusta.de> References: <1146040038.7016.0.camel@laptopd505.fenrus.org> <20060426100559.GC29108@wohnheim.fh-wedel.de> <1146046118.7016.5.camel@laptopd505.fenrus.org> <1146049414.7016.9.camel@laptopd505.fenrus.org> <20060426110656.GD29108@wohnheim.fh-wedel.de> <445061DC.5030008@yahoo.com.au> <1146120640.2894.1.camel@laptopd505.fenrus.org> <20060427083157.GD3570@stusta.de> Content-Type: text/plain Date: Thu, 27 Apr 2006 10:41:12 +0200 Message-Id: <1146127273.2894.21.camel@laptopd505.fenrus.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2006-04-27 at 10:31 +0200, Adrian Bunk wrote: > On Thu, Apr 27, 2006 at 08:50:40AM +0200, Arjan van de Ven wrote: > > On Thu, 2006-04-27 at 09:28 +0300, Pekka J Enberg wrote: > > > On Thu, 27 Apr 2006, Nick Piggin wrote: > > > > Not to dispute your conclusions or method, but I think doing a > > > > defconfig or your personal config might be more representative > > > > of % size increase of text that will actually be executed. And > > > > that is the expensive type of text. > > > > > > True but I was under the impression that Arjan thought we'd get text > > > savings with GCC 4.1 by making kfree() inline. > > > > not savings in text size, I'll settle for the same size. > >... > > It will always be bigger since there are cases where it's unknown at > compile time whether it will be NULL when called. if it's "unknown" you could call into a separate kfree() which does check out of line. (sure that's a dozen bytes bigger but that is noise ;)