On Wed, 23 May 2007, Peter Zijlstra wrote: > On Wed, 2007-05-23 at 10:40 -0400, Jason Baron wrote: > > On Wed, 23 May 2007, Peter Zijlstra wrote: > > > > > Count lock contention events per lock class. Additionally track the first > > > four > > > callsites that resulted in the contention. > > > > > > > I think that we need the total number of locking calls, not just the total > > number of *contended* locking calls, in order to make the data > > significant. Same for waittime. Yes, this pollutes the fastpath. In the > > contention case, its one extra addition, and for the waittime, its a call > > the sched_clock(). I don't think that's too much to pay for much more > > meaningful data. > > The holdtime statistics add these numbers. >
ok, i see what you are saying...however, the 'waittime' statistic as implemented, is only recorded when we don't get the lock immediately. Thus, it's really measuring the waittime when there is lock contention. I understand that in the non-contended case we are only talking a a few cycles, but the fact that the non-contended case is not counted as another waittime of even zero length (so no measurement is required), might skew the stats a bit. For examples, if there was a lock that was almost never contended but one time happened to be contended for a long time, its average wait time would look really high. thanks, -Jason - 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/