Re: [PATCH] remove redundant NULL checks before kfree() in drivers/video/

[Antonino A. Daplas]

On Monday 21 March 2005 06:02, Jesper Juhl wrote:
> On Mon, 21 Mar 2005, Antonino A. Daplas wrote:
> > On Sunday 20 March 2005 06:59, Jesper Juhl wrote:
> > > Checking a pointer for NULL before calling kfree() on it is redundant,
> > > kfree() deals with NULL pointers just fine.
> > > This patch removes such checks from files in drivers/video/
> > >
> > > Since this is a fairly trivial change (and the same change made
> > > everywhere) I've just made a single patch for all the files and CC all
> > > authors/maintainers of those files I could find for comments. If
> > > spliting this into one patch pr file is prefered, then I can easily do
> > > that as well.
> >
> > [snip]
> >
> > > --- linux-2.6.11-mm4-orig/drivers/video/console/bitblit.c	2005-03-16
> > > 15:45:26.000000000 +0100 +++
> > > linux-2.6.11-mm4/drivers/video/console/bitblit.c	2005-03-19
> > > 22:27:39.000000000 +0100 @@ -199,8 +199,7 @@ static void
> > > bit_putcs(struct vc_data *vc
> > >  		count -= cnt;
> > >  	}
> > >
> > > -	if (buf)
> > > -		kfree(buf);
> > > +	kfree(buf);
> > >  }
> >
> > This is performance critical, so I would like the check to remain. A
> > comment may be added in this section.
>
> Ok, I believe Andrew already merged the patch into -mm, if you really want
> that check back then I'll send him a patch to put it back and add a
> comment once he puts out the next -mm.
> But, at the risk of exposing my ignorance, I have to ask if it wouldn't
> actually perform better /without/ the if(buf) bit?  The reason I say that
> is that the generated code shrinks quite a bit when it's removed, and also
> kfree() itself does the same NULL check as the very first thing, so it
> comes down to the bennefit of shorter generated code, one less branch,
> against the overhead of a function call - and how often will 'buf' be
> NULL? if buff is != NULL the majority of the time, then it should be a
> gain to remove the if().

You said it, buf is almost always NULL, except when the driver is in
monochrome mode.  So a kfree is rarely done.

Anyway, if the patch is already in the tree, let's leave it at that.  I would
surmise that the performance loss is negligible.

Tony


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/