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

[Dan Gibson <degibson@xxxxxxxx>]

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.
>
>
>