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

["Shougata Ghosh (shougata@xxxxxxxxxxxxx)" <shougata@xxxxxxxxxxxxx>]

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.