Hi, Really appreciate your help on this issue! 1. using root solve my problem with "perf lock", thank you very much! 2. about the discussion on locks in user-space. I discussed this with my advisor, and found that lock contention does not mean waiting time or idle cpu-cycles sometime, for example, spin-lock in user-space that all threads/cores are still running but useless work and this cannot be detected as either system lock or idle-cpu-cycles. The way, I am trying to do this, now is insert the counter into the application layer once the lock happens start the counting and I prepare to monitor the threads in queue to detect the lock.
I will let you know if I have any updates on this. Again thank you all for your help and discussions. Thanks! Best Junjie On Saturday, March 1, 2014 10:04 AM, Rodrigo Campos <rodr...@sdfg.com.ar> wrote: On Sat, Mar 01, 2014 at 08:30:47AM -0700, David Ahern wrote: > On 2/28/14, 11:43 AM, Rodrigo Campos wrote: > >There are ways (not sure if the patch is in) to track for lock contension > >using > >perf, but not sure (I think not easy at least) if the lock is not contended. > >As, > >if using glibc, lot of locks are implemented using futex and then solved > >entirely in userspace lot of times (at least without contention). > > What patch are you referring to? You can trace system calls to catch I think one from you, from late last year. I'm not sure and I'm not on my notebook right now. Something to trace the futex syscall or something like that ? That can help to understand lock contention on userspace Thanks, Rodrigo -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
