Folks, (and Stephane)
Recently, a user has spotted a bug on two IA64 implementations...An old
2 way ITA2 running 2.4.x and a small Altix system running 2.6.9 with
PAPI.
It only showed up on heavily threaded codes...The symptom was failures
from the PAPI thread handling...The culprit was that the locking inside
of PAPI was not working under load on this platform. It would work to a
certain degree, but after a while, it would either fail to preserve the
mutex or worse, all threads would deadlock.
Replacing the locks with semaphores on this platform solved the problem.
Semaphores suck however...and are about as slow as you can possibly get
for mutex's.
I would ask someone to review the following code for correctness. PAPI's
locks simply busy-wait for the lock to be free. There is an array of
about 6 locks used in various portions of the code.
Here are the macros:
extern volatile unsigned int _papi_hwd_lock_data[PAPI_MAX_LOCK];
#define MUTEX_OPEN (unsigned int)1
#define MUTEX_CLOSED (unsigned int)0
#define _papi_hwd_lock(lck) \
{ uint64_t res = 0; \
do { \
__asm__ __volatile__ ("mov ar.ccv=%0;;" :: "r"(MUTEX_OPEN));
\
__asm__ __volatile__ ("cmpxchg4.acq %0=[%1],%2,ar.ccv" :
"=r"(res) : "r"(&_papi_hwd_lock_data[lck]), "r"(MUTEX_CLOSED) :
"memory"); \
} while (res != (uint64_t)MUTEX_OPEN); }
#define _papi_hwd_unlock(lck)
{ uint64_t res = 0; \
__asm__ __volatile__ ("xchg4 %0=[%1],%2" : "=r"(res) :
"r"(&_papi_hwd_lock_data[lck]), "r"(MUTEX_OPEN) : "memory"); }
#endif
If anyone has any idea, I'd love to hear it. One system had a gcc 2.95
compiler and one had a gcc 3.x compiler...
However, many, users ran the exact same test case without problems on
their machines. I'd love to isolate this problem to a compiler rev or
something so I can not use MUTEX's in this substrate.
Thanks.
Philip
P.S. Karl, can you tell us what the rev of compiler was on the Altix?
_______________________________________________
perfmon mailing list
[email protected]
http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
