From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964800AbWFXM1r (ORCPT ); Sat, 24 Jun 2006 08:27:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S933069AbWFXM1r (ORCPT ); Sat, 24 Jun 2006 08:27:47 -0400 Received: from pentafluge.infradead.org ([213.146.154.40]:54468 "EHLO pentafluge.infradead.org") by vger.kernel.org with ESMTP id S933050AbWFXM1r (ORCPT ); Sat, 24 Jun 2006 08:27:47 -0400 Subject: Re: [PATCH] ext3_clear_inode(): avoid kfree(NULL) From: Arjan van de Ven To: Steven Rostedt Cc: Andrew Morton , Jeff Garzik , linux-kernel@vger.kernel.org, torvalds@osdl.org In-Reply-To: References: <200606231502.k5NF2jfO007109@hera.kernel.org> <449C3817.2030802@garzik.org> <20060623142430.333dd666.akpm@osdl.org> <1151151104.3181.30.camel@laptopd505.fenrus.org> Content-Type: text/plain Date: Sat, 24 Jun 2006 14:27:39 +0200 Message-Id: <1151152059.3181.37.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 Sat, 2006-06-24 at 08:20 -0400, Steven Rostedt wrote: > On Sat, 24 Jun 2006, Arjan van de Ven wrote: > > > > > > > > > Because at that callsite, NULL is the common case. We avoid a do-nothing > > > function call most of the time. It's a nano-optimisation. > > > > but a function call is basically free, while an if () is not... even > > with unlikely()... > > > > sounds like a misoptimization to me. > > > > How is a function call free when an if is not? in general, a function call is 100% predictable without any real control flow dependencies for the processor, and thus there is no real issue in the execution pipeline. An if is a conditional branch, which breaks up the execution pipeline if mispredicted... > Especially if that > function does the exact same if? sure; but to call this code an optimization ... it's just extra code.