On 9/16/05, Robin Holt <holt@sgi.com> wrote: > Can you site one instance where it is more helpful to know that _ANY_ > lock in the system is hitting ia64_spinlock_contention as opposed to > the function which has the spin_lock() code? I can recall times when > network traffic was contending on locks and causing my application to > appear to have a contended lock. With this change, at least we know > the degradation is do to something external. Not sure if I can help siting it, but I can cite one recent example: I was looking at a profile of a test which wasn't supposed to have any contention. Yet, ia64_spinlock_contention unexpectedly showed up fairly high in the profile. Turns out it was due to some left-over debug code. Of course, I was using q-syscollect so it was easy to see who was calling the spinlock contention routine a lot... --david -- Mosberger Consulting LLC, voice/fax: 510-744-9372, http://www.mosberger-consulting.com/ 35706 Runckel Lane, Fremont, CA 94536 - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Sat Sep 17 11:09:29 2005
This archive was generated by hypermail 2.1.8 : 2005-09-17 11:09:36 EST