Messages in this thread | | | Date | Thu, 4 Jan 2007 00:12:50 -0800 | Subject | Re: [PATCH] lock stat for -rt 2.6.20-rc2-rt2.2.lock_stat.patch | From | Bill Huey (hui) <> |
| |
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 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/
| |