lkml.org 
[lkml]   [2010]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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?



\
 
 \ /
  Last update: 2010-03-18 21:33    [W:0.139 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site