Re: dentry bloat.
From: Linus Torvalds
Date: Fri May 14 2004 - 09:46:18 EST
On Fri, 14 May 2004, Dipankar Sarma wrote:
> > 2.6.6 10280 110
> > 2.6.6-bk 10862 30
> > To find out if the huge performance dip between the 2.6.6
> > and 2.6.6-bk is because of the hash changes, I removed the hash patch
> > from 2.6.6-bk and applied it to 2.6.6.
> > 2.6.6-bk with old hash 10685 34
> > 2.6.6 with new hash 10496 125
> > Looks like the new hashing function has brought down the performance.
> > Also some code outside dcache.c and inode.c seems to have pushed down
> > the performance in 2.6.6-bk.
> OK, I am confused. These numbers show that the new hash function
> is better.
No, look again.
old hash new hash
2.6.6: 10280 10496
2.6.6-bk: 10685 10862
in both cases, the new hash makes each iteration about ~200us (or whatever
the metric is) slower.
There's something _else_ going on too, since plain 2.6.6 is so clearly
better than the others. I don't know why - the only thing -bk does is the
hash change and some changes to GFP_NOFS behaviour (different return value
from shrink_dentries or whatever). Which shouldn't even trigger, I'd have
assumed this is all cached.
NOTE! Just "simple" things like variations in I$ layout of the kernel code
can make a pretty big difference if you're unlucky. And the new dentry
code doesn't align the things on a D$ cache line boundary, so there could
easily be "consistent" differences from that - just from the order of
dentries allocated etc.
But it's interesting to note that the hash does make a difference. The old
hash was very much optimized for simplicity (those hash-calculation
routines are some of the hottest in the kernel). But I don't see that a
few extra instructions should make that big of a difference.
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/