Re: [Gems-users] Running SPLASH2 benchmarks with LogTM

[Shougata Ghosh <shougata@xxxxxxxxxxxxx>]

Hi Kevin

Thanks for looking into it.
I ran a transactional version of barnes which also didn't run :(. Here 
are the parameters I used:
#Ruby parameters
ruby0.setparam g_NUM_PROCESSORS 16
ruby0.setparam g_PROCS_PER_CHIP 1
ruby0.setparam g_MEMORY_SIZE_BYTES 1073741824

ruby0.setparam L1_CACHE_NUM_SETS_BITS 16
ruby0.setparam L2_CACHE_NUM_SETS_BITS 16

ruby0.setparam MEMORY_RESPONSE_LATENCY_MINUS_2 1
ruby0.setparam SIMICS_RUBY_MULTIPLIER 1
ruby0.setparam CACHE_RESPONSE_LATENCY 1
ruby0.setparam L1_RESPONSE_LATENCY 1
ruby0.setparam L2_RESPONSE_LATENCY 2

#Transactional Memory Params
ruby0.setparam_str REMOVE_SINGLE_CYCLE_DCACHE_FAST_PATH true
ruby0.setparam_str PROFILE_EXCEPTIONS false
ruby0.setparam_str PROFILE_XACT true
ruby0.setparam RETRY_LATENCY 100
ruby0.setparam g_DEADLOCK_THRESHOLD 400000

And I got this error:

Runtime Error at ../protocols/MESI_SMP_LogTM_directory-cache.sm:330, 
Ruby Time: 2388585: assert failure, PID: 6553
press return to continue.

***  Simics getting shaky, switching to 'safe' mode.
***  Simics (main thread) received an abort signal, probably an assertion.

This happened after the first commit.

I do want to mention that I made a change in command.C to run my 
transactional benchmarks. I noticed that in GEMS-1.4, the parameter 
passed through the magic instructions are different for BEGINs and 
COMMITs. In GEMS-1.3, BEGINs had 20 added to the transaction ID and 
COMMITs had 40 added to the transaction IDs. This is how the code looked 
in GEMS-1.3: inside commands.C's magic_instruction_callback() function:
} else if (val >= 20 && val < 40){ // Begin Atomic Memory Transaction
   id = val - 20;
   assert(true == Protocol::m_XactMemory);
   XACT_MGR->beginTransaction(id);
 } else if (val >= 40 && val < 60){ // Commit Atomic Memory Transaction
   id = val - 40;
   assert(true == Protocol::m_XactMemory);
   XACT_MGR->commitTransaction(id);
 }

In GEMS-1.4, it looks like the following:

} else if (val >= 1024 && val < 2048) {
   // begin closed
   id = val - 1024;
   XACT_MGR->beginTransaction(id);
   //}    else if (val >= min_closed_commit && val < XACT_OPEN_MIN_ID) {
 }    else if (val >= 2048 && val < 3072) {
   // commit closed
   id = val - 2048;
   XACT_MGR->commitTransaction(id);
 } else if (val >= 3072 && val < 4096) {
   // begin open
   id = val - 3072;
   XACT_MGR->beginTransaction(id);
 } else if (val >= 4096 && val < 5120) {
   // commit open
   id = val - 4096;
   XACT_MGR->commitTransaction(id);
 }

Now it seems like transaction depth could go as deep as 1024, as opposed 
to GEMS-1.3's 20. Also, there are two segments for handling begins as 
well as commits, commented with "//commit closed" and "//commit open". I 
am not really sure how this works! Back in GEMS-1.3, the header file 
transaction.h would just add 20 or 40 to the transaction Id in the magic 
instructions. I didn't find any sample transaction.h which uses the new 
notation. So in GEMS-1.4, I changed the ranges to handle val in the 
range of 20 to 60 (since I am still running the old transactional binaries).
Is it possible that my change might have caused these errors? If so, 
could anyone please point out how the new transaction.h file need to be 
changed to be used with GEMS-1.4?
Thanks
shougata


>Shougata,
>
>That's too bad. I would have expected exactly that error running with 
GEMS 1.3, but not GEMS 1.4. I'll try to recreate the problem here.
>
>--Kevin
>
>Shougata Ghosh wrote:
>
>>
>>Sorry for not mentioning in the previous post. I'm running GEMS 1.4 now!
>>
>>>Dan and Kevin
>>>
>>>Thanks a lot for the answers.
>>>
>>>Tourmaline Serializer works with barnes without breaking. But the 
biggest drawback of Serializer for me is that it stalls all other 
processors when it's in a transaction. For my work, I want to model 
conflicts and aborts. Maybe I'll try making some modifications to 
Serializer and see how it goes from there. As you guys suggested, I 
tried running with a larger cache and low latencies. This is the config 
I used:
>>>
>>>#Ruby parameters
>>>ruby0.setparam g_NUM_PROCESSORS 16
>>>ruby0.setparam g_PROCS_PER_CHIP 1
>>>ruby0.setparam g_MEMORY_SIZE_BYTES 1073741824
>>>
>>>ruby0.setparam L1_CACHE_NUM_SETS_BITS 16
>>>ruby0.setparam L2_CACHE_NUM_SETS_BITS 16
>>>
>>>ruby0.setparam MEMORY_RESPONSE_LATENCY_MINUS_2 1
>>>ruby0.setparam SIMICS_RUBY_MULTIPLIER 1
>>>ruby0.setparam CACHE_RESPONSE_LATENCY 1
>>>ruby0.setparam L1_RESPONSE_LATENCY 1
>>>ruby0.setparam L2_RESPONSE_LATENCY 2
>>>
>>>#Transactional Memory Params
>>>ruby0.setparam_str REMOVE_SINGLE_CYCLE_DCACHE_FAST_PATH false
>>>ruby0.setparam_str PROFILE_EXCEPTIONS false
>>>ruby0.setparam_str PROFILE_XACT true
>>>ruby0.setparam RETRY_LATENCY 100
>>>ruby0.setparam g_DEADLOCK_THRESHOLD 400000
>>>
>>>
>>>I changed the function that returns the memory latency to 
MEMORY_RESPONSE_LATENCY_MINUS_2 + 2, so that it always returns 3 and 
does not model the random variation.
>>>
>>>Before running barnes, I wanted to test it with the deque 
transactional microbenchmark and go the following error:
>>>
>>>failed assertion 'm_sequencer->isReady(logMsg)' at fn 
MemoryTransactionResult 
SimicsProcessor::makeRequest(memory_transaction_t*) in 
simics/SimicsProcessor.C:442
>>>
>>>failed assertion 'm_sequencer->isReady(logMsg)' at fn 
MemoryTransactionResult 
SimicsProcessor::makeRequest(memory_transaction_t*) in 
simics/SimicsProcessor.C:442
>>>
>>>At this point you might want to attach a debug to the running and 
get to the
>>>crash site; otherwise press enter to continue
>>>PID: 2452
>>>
>>>
>>>I am not sure if this is caused by something I changed in the 
microbenchmark or it is a ruby issue. I'm trying to run the barnes 
benchmark now to see how it goes. And just to be on the safer side, I 
set REMOVE_SINGLE_CYCLE_DCACHE_FAST_PATH to true.
>>>
>>>As a side, could someone elaborate on how logTM tries to stall the 
conflicting processor instead of aborting it outright? I'm trying to 
understand the protocol since it seems to be different from the paper. 
So when would it fail to stall? As I mentioned earlier, I want to model 
aborts and would like to see as many rollbacks as possible. Also, does 
the attempt to stall a conflicting processor generate the NACKs instead 
of ABORTs?
>>>
>>>I'd really appreciate any feedback.
>>>Thanks
>>>shougata
>>>