Messages in this thread | | | Date | Sat, 8 May 2004 17:10:27 -0700 | From | Andrew Morton <> | Subject | Re: dentry bloat. |
| |
Dipankar Sarma <dipankar@in.ibm.com> wrote: > > On Sat, May 08, 2004 at 01:55:12PM -0700, Andrew Morton wrote: > > Dipankar Sarma <dipankar@in.ibm.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |