On Thu, Oct 08, 2009 at 09:39:30AM +0200, Nick Piggin wrote: > > My point (probably not very well written expressed) > > was that in a typical VFS operation there are hundreds > > of cache lines touched for various things (code, global, various > > objects, random stuff) and one more or less in the final dentry > > is not that big a difference in the global picture. > > (ok I realize final in this case means the elements in the path) > > Yes I do know what you were getting at... Although I would > say dcache is still fairly significant. It's 3 cachelines > for every single path element we look up. Now I suspect it That's true, for deeply nested paths where the elements add up it's a concern. I was assuming that paths are not that deep, but that might be too optimistic. > Actually no, it does look relatively sane (I guess it doesn't > change that much), except it might actualy be a nice idea > to move d_iname up to about above d_lru, so we could actually > do path lookup in 2 cachelines per entry (or even 1 if we > they have very short names). > > I will do a bit of profiling on the lookup code and see... Yes numbers would be great. -Andi -- ak@xxxxxxxxxxxxxxx -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
