On Wed, Jan 03, 2007 at 06:14:11PM -0800, Chen, Tim C wrote: > Bill Huey (hui) wrote: > http://mmlinux.sf.net/public/patch-2.6.20-rc2-rt2.3.lock_stat.patch > > If you can rerun it and post the results, it'll hopefully show the > > behavior of that lock acquisition better. > > Here's the run with fix to produce correct statistics. > > Tim > > @contention events = 848858 > @failure_events = 10 > @lookup_failed_scope = 175 > @lookup_failed_static = 47 > @static_found = 17 ... > [112584, 150, 6 -- 256, 0] {init, kernel/futex.c, 2781} > [597012, 183895, 136277 -- 9546, 0] {mm_init, kernel/fork.c, > 369}
Interesting. The second column means that those can be adaptively spun on to prevent the blocking from happening. That's roughly 1/3rd of the blocking events that happen (second/first). Something like that would help out, but the problem is that contention on that lock in the first place. Also, Linux can do a hell of a lot of context switches per second. Is the number of total contentions (top figure) in that run consistent with the performance degradation ? and how much the reduction of those events by 1/3rd would help out with the benchmark ? Those are the questions in my mind at this moment. bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
