Hi,
Paul Jackson writes:
Even such obvious changes as removing redundant checks doesn't
seem to ensure a performance improvement. Jesper Juhl posted
performance data for such changes in his microbenchmark a couple
of days ago.
It is not a performance issue, it's an API issue. Please note that kfree()
is analogous libc free() in terms of NULL checking. People are checking NULL
twice now because they're confused whether kfree() deals it or not.
Paul Jackson writes:
Maybe we should be following your good advice:
> You don't know that until you profile!
instead of continuing to make these code changes.
I am all for profiling but it should not stop us from merging the patches
because we can restore the generated code with the included (totally
untested) patch.
Pekka
Signed-off-by: Pekka Enberg <[email protected]>
---
Index: 2.6/include/linux/slab.h
===================================================================
--- 2.6.orig/include/linux/slab.h 2005-03-22 14:31:30.000000000 +0200
+++ 2.6/include/linux/slab.h 2005-03-30 09:08:13.000000000 +0300
@@ -105,8 +105,14 @@
return __kmalloc(size, flags);
}
+static inline void kfree(const void * p)
+{
+ if (!p)
+ return;
+ __kfree(p);
+}
+
extern void *kcalloc(size_t, size_t, int);
-extern void kfree(const void *);
extern unsigned int ksize(const void *);
extern int FASTCALL(kmem_cache_reap(int));
Index: 2.6/mm/slab.c
===================================================================
--- 2.6.orig/mm/slab.c 2005-03-22 14:31:31.000000000 +0200
+++ 2.6/mm/slab.c 2005-03-30 09:08:45.000000000 +0300
@@ -2567,13 +2567,11 @@
* 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)
{
kmem_cache_t *c;
unsigned long flags;
- if (!objp)
- return;
local_irq_save(flags);
kfree_debugcheck(objp);
c = GET_PAGE_CACHE(virt_to_page(objp));
@@ -2581,7 +2579,7 @@
local_irq_restore(flags);
}
-EXPORT_SYMBOL(kfree);
+EXPORT_SYMBOL(__kfree);
#ifdef CONFIG_SMP
/**
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
