Re: [Gems-users] Converting barnes (splash2) to use transactions


Date: Sun, 16 Sep 2007 21:49:08 -0400 (EDT)
From: "Deepa Srinivasan" <dsriniv@xxxxxxxx>
Subject: Re: [Gems-users] Converting barnes (splash2) to use transactions
OK. I'll look for the gems 2.0 release. Thanks for your help.

- Deepa

> I cannot think of a simple way to catch a bug in this case. We have also
> not tested LogTM with
> Simics 3.0.x. I am not sure if there are any issues there.
>
> On a side note, we will be releasing GEMS 2.0 shortly. It will have a
> much more stable implementation
> of LogTM-SE and more built-in debugging features. It should make your
> job easier. I would recommend waiting
> for it if you have a couple of weeks in hand.
>
> Jayaram
>
> Deepa Srinivasan wrote:
>> Jayaram,
>>
>> Thanks for the suggestions. I tried both options:
>>
>> - I didn't have any compiler optimizations enabled before. But I
>> explicitly disabled them using "gcc -O0" & recompiled. It still crashes
>> (at the same point in the simulation as before).
>> - Next, I tried using the modified macro you suggested below as well and
>> still results in the application crash.
>>
>> Trying to find any other ways to resolve this problem - any other
>> suggestions?
>>
>> Thanks,
>> Deepa
>>
>>
>>> Deepa,
>>>
>>>
>>> Your approach to 'transactifying' barnes looks correct. At what
>>> optimization level are you compiling Barnes? I would try to compile
>>> Barnes
>>> with optimizations turned off and see if the program works then.
>>>
>>> You might also want to modify the transaction macro:
>>>
>>> : "l0" /* clobber register */, "memory"                     \
>>>
>>>
>>> to ensure that the compiler doesn't carry live register values across
>>> transaction boundaries
>>>
>>> Jayaram
>>>
>> --------------------------
>>
>>> Deepa Srinivasan wrote
>>>
>>>     I'm trying to use transactions in place of locks in the Barnes
>>> application
>>>     from the splash2 suite, with the logTM code. When I run the
>>> converted
>>>     application with 2 application threads on a 2-CPU Simics
>>> configuration, it
>>>     runs ok. But, when I try the same binary on a 4-CPU configuration,
>>> with 4
>>>     application threads, the Barnes application crashes. The simulated
>>> system
>>>     or Simics do not crash. At this point, I'm able to save & copy out
>>> the
>>>     core file from the crash. Examining the core file (offline, on a
>>> different
>>>     system) does not offer any clues - the stack itself seems to be
>>> corrupted.
>>>
>>>     I use gems1.3 and Simics3.0.15.
>>>
>>>     I turned on logTM debug messages, but didn't turn out to be very
>>> useful.
>>>     I'm now trying to capture & analyze cache debug messages as well as
>>> logTM.
>>>
>>>     But, I'd like to make sure that I'm doing the transactional-izing
>>> of
>>> the
>>>     barnes code accurately.
>>>
>>>     Below is the transaction code from barnes (load.C) that causes the
>>> crash:
>>>     (the commented out ALOCK and AULOCK calls are the old locks code).
>>>     ..............
>>>     (loadtree() function)
>>>
>>>           if (*qptr == NULL) {
>>>              /* lock the parent cell */
>>>              //ALOCK(CellLock->CL, ((cellptr) mynode)->seqnum %
>>> MAXLOCK);
>>>     BEGIN_TRANSACTION(3);
>>>              if (*qptr == NULL) {
>>>                 le = InitLeaf((cellptr) mynode, ProcessId);
>>>                 Parent(p) = (nodeptr) le;
>>>                 Level(p) = l;
>>>                 ChildNum(p) = le->num_bodies;
>>>                 ChildNum(le) = kidIndex;
>>>                 Bodyp(le)[le->num_bodies++] = p;
>>>                 *qptr = (nodeptr) le;
>>>                 //printf("Xn 3 Level %d\n", l);
>>>                 flag = FALSE;
>>>              }
>>>              //AULOCK(CellLock->CL, ((cellptr) mynode)->seqnum %
>>> MAXLOCK);
>>>     COMMIT_TRANSACTION(3);
>>>              /* unlock the parent cell */
>>>           }
>>>           if (flag && *qptr && (Type(*qptr) == LEAF)) {
>>>              /*   reached a "leaf"?      */
>>>              //ALOCK(CellLock->CL, ((cellptr) mynode)->seqnum %
>>> MAXLOCK);
>>>     BEGIN_TRANSACTION(4);
>>>              /* lock the parent cell */
>>>              if (Type(*qptr) == LEAF) {             /* still a "leaf"?
>>>  */
>>>                 le = (leafptr) *qptr;
>>>                 if (le->num_bodies == MAX_BODIES_PER_LEAF) {
>>>                    *qptr = (nodeptr) SubdivideLeaf(le, (cellptr)
>>> mynode,
>>> l,
>>>                                                       ProcessId);
>>>                 }
>>>                 else {
>>>                    Parent(p) = (nodeptr) le;
>>>                    Level(p) = l;
>>>                    ChildNum(p) = le->num_bodies;
>>>                    Bodyp(le)[le->num_bodies++] = p;
>>>                    flag = FALSE;
>>>                 }
>>>                 //printf("Xn 4 Level %d\n", l);
>>>              }
>>>              //AULOCK(CellLock->CL, ((cellptr) mynode)->seqnum %
>>> MAXLOCK);
>>>     COMMIT_TRANSACTION(4);
>>>              /* unlock the node           */
>>>           }
>>>     ............
>>>     Here is the definition I have for the transaction macros:
>>>
>>>     #define NEW_RUBY_MAGIC_CALL( service )                      \
>>>         __asm__ __volatile__                                    \
>>>         ( "sethi %1, %%g0  !magic service\n\t"                  \
>>>               : /* no outputs */                                \
>>>           : "r" (0), "i" ((service)<<16)                        \
>>>               : "l0" /* clobber register */                     \
>>>             );
>>>
>>>     #define BEGIN_TRANSACTION(id) NEW_RUBY_MAGIC_CALL((id + 20))
>>>     #define COMMIT_TRANSACTION(id) NEW_RUBY_MAGIC_CALL((id + 40))
>>>     ............
>>>
>>>     Hoping someone who's done this before can tell me if there's
>>> something
>>>     obviously wrong here, in the way I convert to transactions?
>>>
>>>     Thanks for any help.
>>>     - Deepa
>>>
>>>
>>
>> _______________________________________________
>> 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.
>
>

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