All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vernon Mauery <vernux@us.ibm.com>
To: kernel list <linux-kernel@vger.kernel.org>
Subject: Re: kfree(NULL)
Date: Fri, 21 Apr 2006 13:30:30 -0700	[thread overview]
Message-ID: <200604211330.30657.vernux@us.ibm.com> (raw)
In-Reply-To: <20060421192217.GI19754@stusta.de>

On Friday 21 April 2006 12:22, you wrote:
> On Fri, Apr 21, 2006 at 05:07:45PM +0200, Jan Engelhardt wrote:
> > >> Maybe kfree should really be a wrapper around __kfree which does the
> > >> real work.  Then kfree could be a inlined function or a #define that
> > >> does the NULL pointer check.
> > >
> > >NULL pointer check in kfree saves lot of small code fragments in
> > > callers. It is one of many reasons why kfree does it.
> > >Making kfree inline wrapper eliminates this save.
> >
> > How about
> >
> > slab.h:
> > #ifndef CONFIG_OPTIMIZING_FOR_SIZE
> > static inline void kfree(const void *p) {
> >     if(p != NULL)
> >         __kfree(p);
> > }
> > #else
> > extern void kfree(const void *);
> > #endif
> >
> > slab.c:
> > #ifdef CONFIG_OPTIMIZING_FOR_SIZE
> > void kfree(const void *p) {
> >     if(p != NUILL)
> >         _kfree(p);
> > }
> > #endif
> >
> > That way, you get your time saving with -O2 and your space saving with
> > -Os.
>
> What makes you confident that the static inline version gives a time
> saving?

A static inline wrapper would mean that it wouldn't have to make a function 
call just to check if the pointer is NULL.  A simple NULL check is faster 
than a function call and then a simple NULL check.  In other words, there 
would be no pushing and popping the stack.  In almost all cases, replacing an 
inline function with a non-inline function means a trade-off between speed 
and size.

--Vernon

  reply	other threads:[~2006-04-21 20:30 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-21  7:03 kfree(NULL) Daniel Walker
2006-04-21  7:22 ` kfree(NULL) James Morris
2006-04-21  8:54   ` kfree(NULL) Andrew Morton
2006-04-21 13:56     ` kfree(NULL) Vernon Mauery
2006-04-21 14:07       ` kfree(NULL) Dmitry Fedorov
2006-04-21 15:07         ` kfree(NULL) Jan Engelhardt
2006-04-21 19:22           ` kfree(NULL) Adrian Bunk
2006-04-21 20:30             ` Vernon Mauery [this message]
2006-04-21 20:54               ` kfree(NULL) Steven Rostedt
2006-04-21 21:38               ` kfree(NULL) Adrian Bunk
2006-04-22 11:56               ` kfree(NULL) Jörn Engel
2006-04-21 23:55     ` kfree(NULL) Paul Mackerras
2006-04-22  7:43       ` kfree(NULL) Pekka Enberg
2006-04-22  8:48         ` kfree(NULL) Paul Mackerras
2006-04-22 15:02           ` kfree(NULL) Pekka Enberg
2006-04-22 18:57           ` kfree(NULL) Hua Zhong
2006-04-22 19:05             ` kfree(NULL) Nick Piggin
2006-04-22 19:22               ` kfree(NULL) Hua Zhong
2006-04-22 19:25                 ` kfree(NULL) Nick Piggin
2006-04-22 20:18                   ` kfree(NULL) Jan Engelhardt
2006-04-23 16:50               ` kfree(NULL) Steven Rostedt
2006-04-22 11:34       ` kfree(NULL) Jesper Juhl
2006-04-21 14:06   ` kfree(NULL) Daniel Walker
     [not found] <63XWg-1IL-5@gated-at.bofh.it>
     [not found] ` <63YfP-26I-11@gated-at.bofh.it>
     [not found]   ` <63ZEY-45n-27@gated-at.bofh.it>
2006-04-21 15:25     ` kfree(NULL) Tilman Schmidt
2006-04-21 16:03       ` kfree(NULL) Daniel Walker
2006-04-21 17:48         ` kfree(NULL) Jörn Engel
2006-04-21 18:00         ` kfree(NULL) Steven Rostedt
2006-04-21 18:42           ` kfree(NULL) Daniel Walker
2006-04-21 18:56             ` kfree(NULL) Steven Rostedt
2006-04-21 19:26           ` kfree(NULL) Andrew Morton
  -- strict thread matches above, loose matches on Subject: below --
2006-04-21 21:02 kfree(NULL) Hua Zhong
2006-04-21 21:11 ` kfree(NULL) Daniel Walker
2006-04-21 21:36   ` kfree(NULL) Michael Buesch
2006-04-21 21:42 ` kfree(NULL) Andrew Morton
2006-04-21 21:48   ` kfree(NULL) Andrew Morton
2006-04-21 22:53   ` kfree(NULL) Hua Zhong
2006-04-21 22:58     ` kfree(NULL) Daniel Walker
2006-04-21 23:03       ` kfree(NULL) Hua Zhong
2006-04-21 23:25     ` kfree(NULL) Andrew Morton
2006-04-21 23:27     ` kfree(NULL) Andrew Morton
2006-04-22 11:18   ` kfree(NULL) Jan Engelhardt
2006-04-22 12:05 kfree(NULL) linux

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200604211330.30657.vernux@us.ibm.com \
    --to=vernux@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.