On Thu, Feb 08, 2007 at 01:01:21AM -0800, Bill Huey wrote: > Christoph, > > The i_mutex lock the inode structure is also a source of contention > heavy when running a lot of parallel "find"s. I'm sure that folks > would be open to hearing suggestions regarding how to fix that. Christoph, And while you're at it, you should also know that dcache_lock is next in line to be nixed out of existence if possible. i_mutex is a bitch and I'm not even going to think about how to get rid of it since it's so widely used in many places (file systems aren't my think as well). Maybe some more precise tracking of contention paths would be useful to see if there's a pathological case creating a cascade of contention events so that can be nixed, don't know. About 1/10th of the lock stat events I've logged report that the owner of the rtmutex is the "current" on a runqueue some where. An adaptive lock would help with those contention events (spin for it while owner is running for the mutex release) but really, the contention should be avoided in the first place since they have a kind of (I think) polynomial increase in contention time as you add more processors to the mix. I have an adaptive lock implementation in my tree that eliminates the contention between what looks like the IDE layer, work queues and the anticipatory scheduler, but that's not a real problem unlike what I've mentioned above. I can get you and others more specifics on the problem if folks working on the lower layers want it. Other than that the -rt patch does quite well with instrumenting all sort of kernel behaviors that include contention and latency issues. So I don't need to tell you how valuable the -rt patch is for these issues since it's obvious, and I'm sure that you'll agree, that it's been instrumental at discovering many problems with the stock kernel. bill - 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
