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