lockmeter
[Top] [All Lists]

Re: [Lse-tech] Re: Lockmeter 1.4.10 problem

To: John Hawkes <hawkes@xxxxxxx>
Subject: Re: [Lse-tech] Re: Lockmeter 1.4.10 problem
From: Dipankar Sarma <dipankar@xxxxxxxxxx>
Date: Mon, 17 Dec 2001 17:00:02 +0530
Cc: maneesh@xxxxxxxxxx, hawkes@xxxxxxxxxxx, lse-tech <lse-tech@xxxxxxxxxxxxxxxxxxxxx>, lockmeter@xxxxxxxxxxx
In-reply-to: <004101c184ca$bee31d60$6601a8c0@xxxxxxxxx>; from hawkes@xxxxxxx on Fri, Dec 14, 2001 at 10:11:25AM -0800
References: <20011214202613.C17111@xxxxxxxxxx> <004101c184ca$bee31d60$6601a8c0@xxxxxxxxx>
Reply-to: dipankar@xxxxxxxxxx
Sender: owner-lockmeter@xxxxxxxxxxx
User-agent: Mutt/1.2.5i
Hi John,

On Fri, Dec 14, 2001 at 10:11:25AM -0800, John Hawkes wrote:
> > The changes you have done for atomic_dec_and_lock() in Lockmeter
> v1.4.10
> > does not seem to give correct statistics.
> 
> I'm guessing that you're looking at i386, which I believe means that the
> code that executes is found in arch/i386/lib/dec_and_lock.c, right?
> That implementation has a "fast path" that uses a direct asm sequence
> using cmpxchgl, and a "slow path" that invokes spin_lock() and
> spin_unlock().  Lockmeter, of course, will only instrument this "slow
> path".  You simply won't see any 1.4.9 statistics for the "fast path".

AFAICS, the cmpxchgl code has nothing to do with the lock, it is used
with the reference counter. If refcount is not zero, the lock is
*not* taken. By taking the lock every time on invocation, the current
lockmeter skews the real picture that is the acquisition of the
global lock.

Thanks
Dipankar
-- 
Dipankar Sarma  <dipankar@xxxxxxxxxx> http://lse.sourceforge.net
Linux Technology Center, IBM Software Lab, Bangalore, India.

<Prev in Thread] Current Thread [Next in Thread>