Messages in this thread | | | Date | Sat, 20 Mar 2010 14:51:11 +0900 | From | Hitoshi Mitake <> | Subject | Re: [PATCH RFC 00/11] lock monitor: Separate features related to lock |
| |
On 03/19/10 05:30, Frederic Weisbecker wrote: > On Thu, Mar 18, 2010 at 02:49:38PM +0900, Hitoshi Mitake wrote: >> Unfortunately, we cannot use this detection method. >> Because trylock series (e.g. spin_trylock()) only issues >> lock_acquire() like this, >> >> static inline int __raw_spin_trylock(raw_spinlock_t *lock) >> { >> preempt_disable(); >> if (do_raw_spin_trylock(lock)) { >> spin_acquire(&lock->monitor, 0, 1, _RET_IP_);<- spin_acquire() only >> issues lock_acquire() >> return 1; >> } >> preempt_enable(); >> return 0; >> } >> >> So distinguishing trylocks and lock_acquire()/lock_release() pairs from >> might_lock_read(), might_fault() and etc is hard. >> >> It seems that turning off PROVE_LOCKING must be required >> for state machine of perf lock. > > > No that's really not a problem. trylocks are pointless in latency > profiling because by definition they don't content. OTOH, they > grab the lock and other locks might wait and raise latencies. So > they are part of the profile. But we don't care about having the > usual acquire/aquired/release sequence as we have the flags that > tell us if this is a trylock. > > So we just need to consider that acquire:try_lock - release is > a right lock scenario, but that acquire - release is only a lockdep > check.
Ah, I see. The argument flags of lock_acquire event can be used for distinguishing try or read lock and pure verifying.
Thanks, Hitoshi
| |