Re: dentry bloat.
From: Andrew Morton
Date: Sat May 08 2004 - 15:57:23 EST
Dipankar Sarma <dipankar@xxxxxxxxxx> wrote:
> > And yes, removing d_movecount would be ok by then, as long as we re-test
> > the parent inside d_lock (we don't need to re-test "hash", since if we
> > tested the full name inside the lock, the hash had better match too ;)
> There are couple of issues that need to be checked -
> 1. Re-doing the parent comparison and full name under ->d_lock
> need to be benchmarked using dcachebench. That part of code
> is extrememly performance sensitive and I remember that the
> current d_movecount based solution was done after a lot of
> benchmarking of various alternatives.
There's a speed-space tradeoff here as well. Making the dentry smaller
means that more can be cached, which reduces disk seeks. On all
But yes, when I've finished mucking with this I'll be asking you to put it
all through your performance/correctness/stress tests please.
One thing which needs to be reviewed is the layout of the dentry, too.
> 2. We need to check if doing ->d_compare() under ->d_lock will
> result in locking hierarchy problems.
Yup, I checked that. Is OK. It's hard to see how a ->d_compare
implementation could care. And ->d_compare is called under dcache_lock
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/