Messages in this thread | | | Date | Sat, 8 May 2004 13:55:12 -0700 | From | Andrew Morton <> | Subject | Re: dentry bloat. |
| |
Dipankar Sarma <dipankar@in.ibm.com> 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 machines...
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 in 2.4.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |