Re: dentry bloat.

From: Andrew Morton
Date: Sat May 08 2004 - 19:13:23 EST


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/