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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 23 May 2007 12:11:15 -0400 (EDT)
From:	Jason Baron <jbaron@...hat.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Bill Huey <billh@...ppy.monkey.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Christoph Hellwig <hch@...radead.org>
Subject: Re: [PATCH 3/7] lockdep: lock contention tracking

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/