On Thu, Mar 21, 2013 at 10:33:27PM -0700, Linus Torvalds wrote: > Ok, that's kind of ugly, but shouldn't be a correctness issue. It > should still work - just cycle through inodes quite aggressivelydue to > no longer re-using them - so I suspect Dave could test it (with the > extra line removed I pointed out just a moment ago). > > And I wonder how big of a deal the aggressive dentry deletion is. > Maybe it's even ok to allocate/free the inodes all the time. The whole > "get the inode hash lock and look it up there" can't be all that > wonderful either. It takes the inode->i_lock for each entry it finds > on the hash list, which looks horrible. I suspect our slab allocator > isn't much worse than that, although the RCU freeing of the inodes > could end up being problematic.
Hell knows... At the very least, I'd expect /proc/self to be fairly hot. During the boot time - /proc/mounts, /proc/filesystems, /proc/cmdline... Dunno. Would be interesting to slap a printk into proc_lookup_de() and see how much (and what) does it hit on a busy system... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
