Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261258AbVDICSu (ORCPT ); Fri, 8 Apr 2005 22:18:50 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261259AbVDICSu (ORCPT ); Fri, 8 Apr 2005 22:18:50 -0400 Received: from mail.dif.dk ([193.138.115.101]:62353 "EHLO saerimmer.dif.dk") by vger.kernel.org with ESMTP id S261258AbVDICSr (ORCPT ); Fri, 8 Apr 2005 22:18:47 -0400 Date: Sat, 9 Apr 2005 04:21:18 +0200 (CEST) From: Jesper Juhl To: Jesper Juhl Cc: Paul Jackson , Pekka J Enberg , jengelh@linux01.gwdg.de, penberg@gmail.com, rlrevell@joe-job.com, davej@redhat.com, linux-kernel@vger.kernel.org Subject: Re: no need to check for NULL before calling kfree() -fs/ext2/ In-Reply-To: Message-ID: References: <1111825958.6293.28.camel@laptopd505.fenrus.org> <1111881955.957.11.camel@mindpipe> <20050327065655.6474d5d6.pj@engr.sgi.com> <20050327174026.GA708@redhat.com> <1112064777.19014.17.camel@mindpipe> <84144f02050328223017b17746@mail.gmail.com> <20050329184411.1faa71eb.pj@engr.sgi.com> 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: 2284 Lines: 57 On Wed, 30 Mar 2005, Jesper Juhl wrote: > On Tue, 29 Mar 2005, Paul Jackson wrote: > > > Pekka wrote: > > > (4) The cleanups Jesper and others are doing are to remove the > > > _redundant_ NULL checks (i.e. it is now checked twice). > > > > Even such obvious changes as removing redundant checks doesn't > > seem to ensure a performance improvement. Jesper Juhl posted > > performance data for such changes in his microbenchmark a couple > > of days ago. > > > > As I posted then, I could swear that his numbers show: > > > > > Just looking at the third run, it seems to me that "if (likely(p)) > > > kfree(p);" beats a naked "kfree(p);" everytime, whether p is half > > > NULL's, or very few NULL's, or almost all NULL's. > > > > Twice now I have asked Jesper to explain this strange result. > > > I've been kept busy with other things for a while and haven't had the time > to reply to your emails, sorry. As I just said in another post I don't > know how valid my numbers are, but I'll try and craft a few more tests to > see if I can get some more solid results. > > > > > Maybe we should be following your good advice: > > > > > You don't know that until you profile! > > > > instead of continuing to make these code changes. > > > I'll gather some more numbers and post them along with any conclusions I > believe can be drawn from them within a day or two, untill then I'll hold > back on the patches... > Ok, I never got around to doing some more benchmarks, mainly since it seems that people converged on the oppinion that the kfree() cleanups are OK and we can fix up any regressions by inlining kfree if needed (the difference these changes make to performance seem to be small and in the noice anyway). If anyone would /like/ me to do more benchmarks, then speak up and I will do them - I guess I could also build a kernel with an inline kfree() as a comparison.. but, unless someone speaks up I'll just carry on making these kfree() cleanups and not bother with benchmarks... -- Jesper - 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/