Re: [Gems-users] Help: simulation is hanged in LL or EL protocols.

[ritchie wang <ritchie.arch@xxxxxxxxx>]

Hi Polina,

Thanks for your response!

I have read the paper “Performance Pathologies in Hardware
Transactional Memory”.

I have turned on TM debug that is to set  XACT_DEBUG = true and
XACT_DEBUG_LEVEL = 3 in microbench.py  and gotten simulation outputs
with detail TM debug information.

All the EE_perfect protocols can finish my simulations. But the
simulations of all the LL protocols  are hanged as I previously
described.

Limited by the GEMS maillist's post size, I can't  attach the
simulation output and visual files in my mail accessories directly. So
I sent the two files to you. Could you give me some advise on this
problem?

Thank you !
I am looking forward to your response!

Best regards!
Ritchie Wang
20100513

2010/5/13 Polina Dudnik <pdudnik@xxxxxxxxx>:
> Another thing you should consider is turning on transactional debug output,
> because from the output you included it is not quite clear where exactly the
> benchmark is.
>
> These functions:
>  tm_bind_to_cabinet(id+1);
>  Barrier_breaking(&local_sense, id, num_p);
>
> are there to aid the simulation. Barrier_breaking ensures that all threads
> reach a barrier, and once they do it starts the simulation timing mode such
> that all threads start from the same point in the program execution. These
> two functions shouldn't give you a problem as they are not affected by what
> kind of TM system you are running. So, please rerun with TM debug turned on.
>
> Polina
>
>
> On Thu, May 13, 2010 at 9:35 AM, Polina Dudnik <pdudnik@xxxxxxxxx> wrote:
>>
>> Hi Ritchie,
>>
>> Did you read "Performance Pathologies in Hardware Transactional Memory"?
>>
>> Base is a conflict resolution policy. There are also other conflict
>> resolution policies in GEMS. Depending on which conflict resolution policy
>> you use, you may see different behavior and performance. Please try other
>> conflict resolution policies and see if that helps.
>>
>> Polina
>>
>>
>> On Thu, May 13, 2010 at 9:14 AM, ritchie wang <ritchie.arch@xxxxxxxxx>
>> wrote:
>>>
>>> Hi all!
>>>
>>> We are doing some research on transactional memory. We need to run all
>>> the three HTM protocols(EE, LL and EE) on GEMS2.1+SIMICS3. The
>>> benchmarks we use are come from STAMP, Splash-2 and microbenchmarks in
>>> GEMS. All the benchmarks can pass EE protocols such as
>>> EagerCD_EagerVM_Base_NoPred etc. However some benchmarks such as
>>> Barnes, Genome, and Btree can not pass LL or EL protocols even the
>>> most basic protocol----LazyCD_LazyVM_Base. These failed benchmarks
>>> meet similar phenomenon that simulations may be hanged after two
>>> functions in slave function:
>>>
>>>  tm_bind_to_cabinet(id+1);
>>>  Barrier_breaking(&local_sense, id, num_p);
>>>
>>> To make things clear, I use Btree for example. After a simulation is
>>> hanged, the output to monitor is like:
>>>
>>> ... ...
>>> 4 :local_sense = 1
>>> binding to cabinet 6
>>> 3 :ret = 0, count=3
>>> 5 :local_sense = 1
>>> binding to cabinet 7
>>> 4 :mutex locked ...
>>> 6 :local_sense = 1
>>> binding to cabinet 8
>>> 4 :ret = 0, count=4
>>> 7 :local_sense = 1
>>> binding to cabinet 9
>>> 6 :mutex locked ...
>>> 8 :local_sense = 1
>>> binding to cabinet 10
>>> ... ...
>>> 5 :ret = 0, count=14
>>> 6 :mutex unlocked ...
>>> 1 :mutex locked ...
>>> 1 :ret = 1, count=15
>>> 5 :mutex unlocked ...
>>> 1 :mutex unlocked ...
>>> 1 :Before SIMICS_BREAK_EXECUTION, ret = 1, count= 15 .
>>> (The simulation is hanged here.)
>>>
>>> The correspond visual file is looked like:
>>>
>>> ... ...
>>> % $ $ $ $ $ $ $ $ $ $ $ $ $ $ $    145957
>>> % $ $ $ $ $ $ $ $ $ $ $ $ $ $ $    150000
>>> % $ $ $ $ $ $ $ $ $ $ | $ $ $ $    151192
>>> % $ $ $ $ $ $ $ $ $ $ C $ $ $ $    151193
>>> % $ $ $ $ $ $ $ $ $ $ % $ $ $ $    151195
>>> % $ $ $ $ $ $ $ $ $ $ $ $ $ $ $    151290
>>> % $ $ $ $ $ $ $ $ $ $ | $ $ $ $    151725
>>> % $ $ $ $ $ $ $ $ $ $ C $ $ $ $    151726
>>> % $ $ $ $ $ $ $ $ $ $ % $ $ $ $    151726 <=====may be hanged here
>>> % $ $ $ $ $ $ $ $ $ $ $ $ $ $ $    152827
>>> % $ $ $ $ $ $ $ $ $ $ $ $ $ $ $    160000
>>> % $ $ $ $ $ $ $ $ $ $ $ $ $ $ $    170000
>>> % $ $ $ $ $ $ $ $ $ $ $ $ $ $ $    180000
>>> % $ $ $ $ $ $ $ $ $ $ $ $ $ $ $    190000
>>> ... ... (The following pattern is the same)
>>> % $ $ $ $ $ $ $ $ $ $ $ $ $ $ $    2670000
>>> % $ $ $ $ $ $ $ $ $ $ $ $ $ $ $    2680000
>>> % $ $ $ $ $ $ $ $ $ $ $ $ $ $ $    2690000
>>> % $ $ $ $ $ $ $ $ $ $ $ $ $ $ $    2700000
>>> % $ $ $ $ $ $ $ $ $ $ $ $ $ $ $    2710000
>>> (The simulation is aborted now.)
>>>
>>>
>>> I think the reason is that the failed benchmarks meet the same
>>> problem. Could you give me some advise to solve the problem?
>>>
>>>
>>> Thank you !
>>> I am looking forward to your response!
>>>
>>> Best regards!
>>> Ritchie Wang
>>> 20100513
>>> _______________________________________________
>>> 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.
>
>
>