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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
