Re: [PATCH] likely cleanup: remove unlikely for kfree(NULL)

[Adrian Bunk <bunk@stusta.de>]

On Thu, Apr 27, 2006 at 10:41:12AM +0200, Arjan van de Ven wrote:
> 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 ;)

It's noise and _much work.

So in the end, we are removing the current kfree() and replacing them 
with one kfree_can_be_null() and one kfree_cannot_be_null()
(one of them might continue to be called kfree())?

Keeping kfree() as it is today has the advantages:
- smallest code
- noone can forget the NULL check
- KISS

Do you have any benchmarks where your approach brings a measurable 
benefit? I wouldn't have expected kfree() being in many hotpaths.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed