lkml.org 
[lkml]   [2004]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 14:03    [W:0.099 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site