All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bart Hartgers <bart@etpmod.phys.tue.nl>
To: Arjan van de Ven <arjan@infradead.org>
Cc: "Adrian Bunk" <bunk@stusta.de>,
	"Pekka J Enberg" <penberg@cs.Helsinki.FI>,
	"Nick Piggin" <nickpiggin@yahoo.com.au>,
	"Jörn Engel" <joern@wohnheim.fh-wedel.de>,
	"Hua Zhong" <hzhong@gmail.com>,
	linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: [PATCH] likely cleanup: remove unlikely for kfree(NULL)
Date: Thu, 27 Apr 2006 13:41:03 +0200	[thread overview]
Message-ID: <4450ADCF.8040005@etpmod.phys.tue.nl> (raw)
In-Reply-To: <1146128885.2894.27.camel@laptopd505.fenrus.org>

[-- Attachment #1: Type: text/plain, Size: 2008 bytes --]

Arjan van de Ven wrote:
> On Thu, 2006-04-27 at 10:56 +0200, Adrian Bunk wrote:
>> 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.
> 
> not if the compiler can do it. The *compiler* knows a lot (4.1 at
> least)..

I would think so too. Unfortunately this is what I found for make
allyesconfig on 2.6.16.9:

   text    data     bss     dec     hex filename
21615935 7929490 2187672 31733097        1e43569 vmlinux-3.3.5-new
21616824 7929298 2187672 31733794        1e43822 vmlinux-3.3.5-old
21546713 7616546 2184984 31348243        1de5613 vmlinux-4.1.0-new
21546551 7616458 2184984 31347993        1de5519 vmlinux-4.1.0-old

Where "old" is the original one, and "new" the one with the included
patch applied. So the patch is a small win with gcc-3.3.5 and a small
loss on gcc-4.1.0. I don't really understand why 4.1.0 produces larger
code with the patch, but I triple-checked...

Groeten,
Bart




-- 
Bart Hartgers - TUE Eindhoven - http://plasimo.phys.tue.nl/bart/contact/

[-- Attachment #2: null-check.patch --]
[-- Type: text/x-patch, Size: 1125 bytes --]

--- linux-2.6.16.9/include/linux/slab.h	2006-04-19 08:10:14.000000000 +0200
+++ linux-2.6.16.9-kfree/include/linux/slab.h	2006-04-27 11:19:00.000000000 +0200
@@ -123,7 +123,18 @@
 	return kzalloc(n * size, flags);
 }
 
-extern void kfree(const void *);
+extern void __kfree(const void *);
+
+static inline void kfree(const void *ptr)
+{
+	if (__builtin_constant_p(ptr==NULL)) {
+		if (ptr)
+			__kfree(ptr);
+	} else {
+		__kfree(ptr);
+	}
+}
+
 extern unsigned int ksize(const void *);
 
 #ifdef CONFIG_NUMA
--- linux-2.6.16.9/mm/slab.c	2006-04-27 11:24:38.000000000 +0200
+++ linux-2.6.16.9-kfree/mm/slab.c	2006-04-27 11:17:06.000000000 +0200
@@ -3267,7 +3267,7 @@
 EXPORT_SYMBOL(kmem_cache_free);
 
 /**
- * kfree - free previously allocated memory
+ * __kfree - free previously allocated memory
  * @objp: pointer returned by kmalloc.
  *
  * If @objp is NULL, no operation is performed.
@@ -3275,7 +3275,7 @@
  * Don't free memory not originally allocated by kmalloc()
  * or you will run into trouble.
  */
-void kfree(const void *objp)
+void __kfree(const void *objp)
 {
 	struct kmem_cache *c;
 	unsigned long flags;

  reply	other threads:[~2006-04-27 11:41 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-25 18:21 [PATCH] likely cleanup: remove unlikely for kfree(NULL) Hua Zhong
2006-04-26  7:30 ` Pekka Enberg
2006-04-26  7:53   ` Andreas Mohr
2006-04-26  7:58   ` Arjan van de Ven
2006-04-26  8:16     ` Pekka J Enberg
2006-04-26  8:27       ` Arjan van de Ven
2006-04-26 10:05         ` Adrian Bunk
2006-04-26 10:05         ` Jörn Engel
2006-04-26 10:08           ` Arjan van de Ven
2006-04-26 10:57             ` Pekka J Enberg
2006-04-26 11:03               ` Arjan van de Ven
2006-04-26 11:06                 ` Jörn Engel
2006-04-26 11:37                   ` Bart Hartgers
2006-04-26 13:04                     ` Bart Hartgers
2006-04-26 19:07                       ` Kyle Moffett
2006-04-27  6:28                         ` Pekka J Enberg
2006-04-27  6:37                           ` Nick Piggin
2006-04-27  8:17                         ` Bart Hartgers
2006-04-27 15:23                           ` Kyle Moffett
2006-04-26 14:11                   ` Pekka J Enberg
2006-04-27  5:54                   ` Pekka J Enberg
2006-04-27  6:17                     ` Nick Piggin
2006-04-27  6:28                       ` Pekka J Enberg
2006-04-27  6:50                         ` Arjan van de Ven
2006-04-27  8:31                           ` Adrian Bunk
2006-04-27  8:41                             ` Arjan van de Ven
2006-04-27  8:56                               ` Adrian Bunk
2006-04-27  9:08                                 ` Arjan van de Ven
2006-04-27 11:41                                   ` Bart Hartgers [this message]
2006-04-27 18:23                                   ` Adrian Bunk
2006-04-27 18:29                                     ` Arjan van de Ven
2006-04-26 11:05               ` Nick Piggin

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=4450ADCF.8040005@etpmod.phys.tue.nl \
    --to=bart@etpmod.phys.tue.nl \
    --cc=akpm@osdl.org \
    --cc=arjan@infradead.org \
    --cc=bunk@stusta.de \
    --cc=hzhong@gmail.com \
    --cc=joern@wohnheim.fh-wedel.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=penberg@cs.Helsinki.FI \
    /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.