Re: [Gems-users] Tourmaline issues with running microbenchmark tm-deque

[Dan Gibson <degibson@xxxxxxxx>]

I suppose I was wrong about the released controllers. Send me some mail directly to gibson@xxxxxxxxxxx and I'll send you the EagerCDAggressive controller.

Regards,
Dan

Shougata Ghosh (shougata@xxxxxxxxxxxxx) wrote:

Thanks for such a quick reply on a saturday :)
Where exactly can I find these other controllers? The tourmaline that came with GEMS1.3 and 1.3.1 only has
the GenericController and the Serializer. Likewise, where can I find EagerCDAggressive controller?
Thanks a lot
shougata

  

This is an issue that arises when Tourmaline aborts a transaction while it is executing an OS 
event, such as a TLB fill. This can occur in the released version of the Generic controller, which 
was the only nontrivial controller released prior to GEMS 1.3. The Generic controller is intended 
as an example of how a controller should be made, rather than as a foolproof handles-all-cases 
simulator. I believe the subsequent controllers are more robust, though they, too, may still 
experience corner cases.

EagerCDAggressive is the closest controller to the Generic controller -- you might try running with 
that controller instead.

Regards,
Dan Gibson

Shougata Ghosh (shougata@xxxxxxxxxxxxx) wrote:

    

Hi
I'm having problems running the tm-deque microbenchmark with Tourmaline. I modified the tm-deque 
microbenchmark by adding a barrier so that all the parallel threads start running at the same 
time. I wanted to model high contention among the transactional threads. When I run tm-deque with 
10 threads and 30 operations, Tourmaline works fine.
However, when I remove the barrier and then run the microbenchmark again with 10 threads and 30 
operations, the simulated machine crashes! With no barriers and 10 threads and 10 operations, 
tm-deque runs ok.

Here's my complete setup:
-----------------------------------------------------
Simics version 2.2.19
GEMS version 1.3

16 UltraSPARC-III+ processors running Solaris 10.

In the microbenchmark, I bind each thread to a particular processor so that they are not context 
switched during a transaction. Also, I bind the entire microbenchmark to a processor set so that 
it's not conflicting with other running processes.

Tourmaline setup:
Initializing TourmalineConfig... Done.
Creating Transaction Controller:
Controller_type: Generic
number_of_procs: 16
Creating Profiler... Done.

Tourmaline Module Initialized.
Tourmaline Configuration
------------------
simics_version: simics-2.2.19

g_RANDOM_SEED: 1
SPECIFIED_TRANSACTION_CONTROLLER: Generic
g_NUMBER_OF_PROCESSORS: 16
g_NUMBER_OF_ALLOWED_ABORTS: 10
g_SERIALIZATION_WARNING_ENABLE: true
g_PRINT_XACT_STATUS: true
g_SERIALIZER_N_TRANSACTIONS: 0

-------------------------------------------------------

The script used to run the microbenchmark:
#Read in a configuration

#Disable STCs here
dstc-disable

#Disable breakpoint before sync-ing processors
magic-break-disable

#Use 1 cycle cpu-switch-time
cpu-switch-time (1)
c 10000

#Print new cpu switch time
cpu-switch-time

magic-break-enable

load-module tourmaline
tourmaline0.init

run-python-file filename = setup_hap_breakpoint.sh
run-command-file file = setup_run_benchmark.sh

<At the breakpoint, I remove the magic-breakpoint callback hap and load the simcis tracer module>

Here's the output I get in the simulated processor window after tm-deque has run for sometime:

panic[cpu5]/thread=300023c5300: bad kernel MMU trap at TL 2

%tl %tpc              %tnpc             %tstate           %tt
1  0000000000012440  0000000000012444  4482041601        04b
   %ccr: 44  %asi: 82  %cwp: 1  %pstate: 416<MG,PEF,PRIV,IE>
2  000000000100733c  0000000001007340  9182001502        034
   %ccr: 91  %asi: 82  %cwp: 2  %pstate: 15<PEF,PRIV,AG>
%g0-3: 0000000000000000 0000000000000005 0000000005ca2b00 0000000005ca2b00
%g4-7: 000000000000000f 0000000000000034 0000000000000000 0000000000000002
Register window 2, caller 12300
%o0-3: 00000000ff36ba4c 0000000000000610 000000000000000b 0000000000000000
%o4-7: 0000000000000000 0000000084b69543 00000000ff1f3de0 00000000ff36b9d8
%l0-3: 0000000000012440 0000000000012444 0000004482041601 000000000100ae5c
%l4-7: 00000000ff36ba40 00000000ff36ba3c 0000000000000000 00000000ff1f468f
%i0-3: 000000000000005d 0000000000000010 0000000000000004 00000000000002a1
%i4-7: 0000000000000000 00000000425b4aa1 00000000ff1f3f30 0000000000012300
Register window 1, caller ff33fff0
%l0-3: 0000000000000010 0000000000000002 0000000000023a18 0000000000033800
%l4-7: 0000000000033800 0000000000023400 0000000000004001 00000000000fc000
%i0-3: 0000000000000003 00000000ff1fc000 0000000000000000 0000000000000000
%i4-7: 00000000000121e0 0000000000000000 00000000ff1fbfa0 00000000ff33fff0

I'm quite sure the problem is with Tourmaline because it runs fine if I don't load Tourmaline.
Has anyone got any idea what's causing this panic? I'd really appreciate any response.
Thanks a lot
-shougata



_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
      

_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.