Re: [PATCH 3/7] lockdep: lock contention tracking

[Jason Baron <jbaron@redhat.com>]

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 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/