Re: Attribute spinlock contention ticks to caller.

[David Mosberger-Tang <David.Mosberger@acm.org>]

On 9/18/05, Robin Holt <holt@sgi.com> wrote:
> On Fri, Sep 16, 2005 at 06:08:45PM -0700, David Mosberger-Tang wrote:
> > On 9/16/05, Robin Holt <holt@sgi.com> wrote:
> >
> > > Can you site one instance where it is more helpful to know that _ANY_
> > > lock in the system is hitting ia64_spinlock_contention as opposed to
> > > the function which has the spin_lock() code?  I can recall times when
> > > network traffic was contending on locks and causing my application to
> > > appear to have a contended lock.  With this change, at least we know
> > > the degradation is do to something external.
> >
> > Not sure if I can help siting it, but I can cite one recent example: I
> > was looking at a profile of a test which wasn't supposed to have any
> > contention.  Yet, ia64_spinlock_contention unexpectedly showed up
> > fairly high in the profile.  Turns out it was due to some left-over
> > debug code.  Of course, I was using q-syscollect so it was easy to see
> > who was calling the spinlock contention routine a lot...
> 
> That would be a case where you are contending on one lock and you would
> be given the function that was contending.  What I was concerned with
> is where two or more locks are contended and ia64_spinlock_contention
> artificially appears at the top.

Well, it's an example where attributing the spinlock contention time
to the caller would have completely obfuscated the problem.

  --david

-- 
Mosberger Consulting LLC, voice/fax: 510-744-9372,
http://www.mosberger-consulting.com/
35706 Runckel Lane, Fremont, CA 94536