One thing is MUCH more important to me than raw speed or memory
consumption, and your patch fails that test.
That one thing is "simplicity and cleanliness".
The main reason for me to use "kmalloc()" is that it has a conceptually
very simple interface, and I don't need stuff like this:
>+static inline kmem_cache_t * dn_cachep(size_t size)
>+{
>+ int index = 0;
>+
>+ while (size >= dname_cache_sizes[index].cs_size) {
>+ index++;
>+ if (!dname_cache_sizes[index].cs_size)
>+ return NULL;
>+ }
>+
>+ return dname_cache_sizes[index].cs_cachep;
>+}
which I personally find to be extremely tasteless.
If you're worried about kmalloc() not being able to handle the sizes we
want, my opinion is to either change kmalloc itself (so that a 16-byte
array for a name is easy to allocate) or to make another clean allocator
that is generic.
I don't want more of these ad-hoc allocators optimized for one
particular usage and nothing more. I want to have a _generic_ function
that works well, and kmalloc() is generic enough for me.
If you think kmalloc() isn't fast enough or wastes memory, fix _that_,
rather than working around it with the above kinds of things.
I do not believe in using slabs for anything but single-size structures.
For that, slab is fine. For dynamically sized things we want a
kmalloc() type interface - whether it then uses slabs or whatever
internally is totally irrlevant, because only the conceptual interface
has any real relevance.
By using kmalloc(), you can improve _everything_ that uses kmalloc() by
making kmalloc perform better. By writing these specialized allocators
you only add complexity and new failure points with little real gain.
In short, I'm not going to apply something like this.
Linus