Cc: Andrea Arcangeli <andrea@...>, Goswin von Brederlow <brederlo@...>, Andrew Morton <akpm@...>, Nick Piggin <nickpiggin@...>, Christoph Lameter <clameter@...>, <linux-fsdevel@...>, <linux-kernel@...>, Christoph Hellwig <hch@...>, Mel Gorman <mel@...>, William Lee Irwin III <wli@...>, David Chinner <dgc@...>, Jens Axboe <jens.axboe@...>, Badari Pulavarty <pbadari@...>, Maxim Levitsky <maximlevitsky@...>, Fengguang Wu <fengguang.wu@...>, swin wang <wangswin@...>, <totty.lu@...>, <hugh@...>
That sounds pretty good. The problem, of course, is that most of the time,
the actual dentry allocation itself is done before you really know which
case the dentry will be in, and the natural place for actually giving the
dentry lifetime hint is *not* at "d_alloc()", but when we "instantiate"
it with d_add() or d_instantiate().
But it turns out that most of the filesystems we care about already use a
special case of "d_add()" that *already* replaces the dentry with another
one in some cases: "d_splice_alias()".
So I bet that if we just taught "d_splice_alias()" to look at the inode,
and based on the inode just re-allocate the dentry to some other slab
cache, we'd already handle a lot of the cases!
And yes, you'd end up with the reallocation overhead quite often, but at
least it would now happen only when filling in a dentry, not in the
(*much* more critical) cached lookup path.
Linus
-
