Messages in this thread | | | Date | Fri, 14 May 2004 07:44:44 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: dentry bloat. |
| |
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.
Linus - 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/
| |