So I don't know posix mutexex implementation on linux but on HPUX they usually spin first then yield then spin again etc... Until sleep. So tools like perf, reporting cpu consumption showing some mutexes path would reveal the pb. On HPUX, posix mutexes spin/yield/sleep can be tuned through env variables. If this is the same for Linux, you could temporarily set the # of spins to a very high value, to 'emphasize' the hotness of the contention through CPU usage and therefore something 'perf' was meant for since day1.
++Cyrille -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Roland Dreier Sent: Friday, October 14, 2011 9:21 AM To: Maucci, Cyrille Cc: [email protected] Subject: Re: perf for analyzing userspace contention On Thu, Oct 13, 2011 at 11:58 PM, Maucci, Cyrille <[email protected]> wrote: > So are those mutexes acquired/released from different call sites or from one > single generic function of yours like LOCK/UNLOCK and the mutex is passed as > a param? I have lots of code paths taking lots of different classes of locks. My problem is I don't know what to ask perf for to see if I have a mutex that is heavily contended, and so some threads are spending a lot of time asleep waiting to acquire it. As I said, this is probably pretty basic stuff, but I'm not usually much of a userspace guy... Thanks, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
