Re: dentry bloat.

[Andrew Morton]

Dipankar Sarma <dipankar@xxxxxxxxxx> wrote:
>
> On Sat, May 08, 2004 at 01:55:12PM -0700, Andrew Morton wrote:
> > Dipankar Sarma <dipankar@xxxxxxxxxx> wrote:
> > > 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...
> 
> Another thing that would help is the singly linked rcu patch.
> It shaves off 8-bytes per-rcu_head on x86. Should I revive
> that ?
> 

May as well.

> > 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.
> 
> Yes, sure.
> 
> > One thing which needs to be reviewed is the layout of the dentry, too.
> 
> IIRC, Maneesh did some experiments with this and found that any
> changes in the layout he did only degraded performance :)

Well.  Bear in mind that the dentry used to be 256 bytes on a 128 byte
boundary so there was really nothing to improve, unless you were using a
PIII or something.

But I just made it 160 bytes on a 16-byte boundary, so some dentries will
now stradddle cachelines.  We need to identify the used fields on the
lookup path and try to scrunch them into a 16-byte-aligned 16-byte chunk. 
I'll have a go at that.

-
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/