But that's *TWO* things!!!
This was a "patch in progress" for people to fool around with; I
neither expected nor wanted you to apply it. It's a copy of the
grungy crap from the "kmalloc" implementation with the names and faces
changed, and its sole purpose was to quickly test the concept of
separating the allocation of "dentries" and "dnames" from the
allocation of other kernel objects.
Something that's probably more important than "raw speed", "memory
consumption", "simplicity", and "cleanliness" all put together is
having a useable kernel. Without separate kmem caches for the dcache,
my kernel is *not* useable; after about a day and a half of uptime,
and without fail, forks start dying. They keep dying until I've shut
down every user application.
If I move "shrink_dcache" to outside the "do_try_to_free_page" loop so
the "dcache" is shrunk less furiously, or if I put dentries and dnames
into separate kmem caches, my machine stays up, and "find /"'s and
"cvs update"'s don't drive performance into the ground.
I assume what's happening is what I've explained in another message to
the list. "dentries" are freed and reallocated at a tremendous rate
(during normal usage, my counts of active dentries fly from a minimum
of 200-300 to somewhere around 8000-10000 and back). Because some of
them have much longer lifetimes than other kernel objects, there's a
potential for them to checkerboard in the standard kmalloc cache with
short-lived objects. Eventually, a significant number of randomly
positioned pages get "poisoned" by long-lived dcache cruft, and no one
can allocate blocks of continiguous pages.
Imprisoning them in their own cache seems to alleviate this problem:
the maximum number of pages that can possibly be involved is reduced,
and the slightly more uniform lifetimes of the objects involved
results in less fragmentation.
Does someone have a better explanation?
> 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.
I never wanted another specialized allocator. We've got enough damn
specialized allocators, including one staring me in the face from
"fs/inode.c".
I was testing a theory with a 15-minute hack. I know how to implement
it cleanly for real. ("It" meaning a variable-length allocation layer
on top of the slab allocator that segregates objects into distinct
cache-sets---"kmalloc" would run on top of it using one particular
cache-set.) However, I still haven't convinced myself this is the
best way to fix the dcache problem.
Until I do, I'm unlikely to be dissuaded from posting ugly patches for
public consumption just because they aren't production-quality.
Kevin <buhr@stat.wisc.edu>