Messages in this thread | | | Date | Thu, 18 Mar 2010 21:30:50 +0100 | From | Frederic Weisbecker <> | Subject | Re: [PATCH RFC 00/11] lock monitor: Separate features related to lock |
| |
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.
Hm?
| |