The goal of this patchset is to provide a single entry point for kmem_cache_free. Other functions, such as the allocation itself, and kmalloc could easily follow.
The main problem here, is that if we keep the allocator-specific functions in their .c file, we lose the ability to inline their fast paths. Being this such a critical path, we would like to keep doing so. During the last discussion around this (https://lkml.org/lkml/2012/10/22/639), JoonSoo Kim suggested that we could achieve this by just including the allocator-specific .c files in slab_common.c, a suggestion I considered but quickly disregarding fearing a quite ugly end result. Turns out it doesn't look so bad. So please let me know what you think. Thanks Glauber Costa (2): kmem_cache: include allocators code directly into slab_common slab: move kmem_cache_free to common code mm/Makefile | 3 --- mm/slab.c | 23 ++--------------------- mm/slab_common.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++ mm/slob.c | 11 ++++------- mm/slub.c | 5 +---- 5 files changed, 57 insertions(+), 35 deletions(-) -- 1.7.11.7 -- 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/
