Re: [Gems-users] Issues with collecting memory access trace for logtm microbenchmark (tm-deque)


Date: Wed, 10 Jan 2007 18:09:05 -0600
From: Jayaram Bobba <bobba@xxxxxxxxxxx>
Subject: Re: [Gems-users] Issues with collecting memory access trace for logtm microbenchmark (tm-deque)
Hi
*****The biggest issue is with having too many requests. I want to isolate all the other processes making memory requests, except tm-deque.
You should try binding threads to processors. Create processor sets using pset_create and then bind the threads belonging to tm-deque using pset_bind. This will prevent other processes from interfering with your trace. Are you checking the return value in 'ruby_operate' and ensuring that you take the trace
exactly once per memory access (return value should be zero)?
On a side, how does LogTm differentiate xactional requests from non-xactional ones if they both come from the same processor??
The released version of the code does not handle context switches in the middle of a transaction. So once a transaction starts up, all user memory accesses until a transaction commit/abort are
considered transactional.
Why aren't the threads running in parallel?
You might want to put a barrier at the beginning of each thread and start simulation only after all the
threads have been created and hit the barrier.

Jayaram
[← Prev in Thread] Current Thread [Next in Thread→]