Re: [Gems-users] Strange behavior (BARRIER_CYCLE = 0) collected of vacation on LogTM-SE

[Polina Dudnik <pdudnik@xxxxxxxxx>]

I really think you should just double check that your barrier is counting cycles to begin with and also make sure that the program enters the barrier.

On Mon, Oct 26, 2009 at 6:42 AM, ruzhu kao <kaoruzhu@xxxxxxxxx> wrote:

Hi Polina:
 Thanks for your reply.
 I use "-c 16" to set the number of clients to 16 and it should make
vacation run in multi-threaded, is it right? About the path barrier
appearing, I 'll check it, but in the same programming pattern (the
same order to setup logtm states, register and creating thread), could
it only make vacation miss the barrier cycle?
 I have test btree on my testbed, its barrier_cycle is 0. Its
Non_Tran_cycle, Tran_cycle, Committing_cycle, Aborting_cycle,
Backoff_cycle and Stall_cycle show their number of cycle normally.
However, I have test some applications like cholesky , barnes  and
other applications in stamp, them do count the barrier_cycle.
 Do you have any comments on this situation.

Thanks in advance.

Sincerely yours:
Ruzhu

2009/10/26 Polina Dudnik <pdudnik@xxxxxxxxx>:

> Ruzhu,
> Did you turn on all the debugging? Do you see the message that indicates
> that a thread entered the barrier? Because my bet would be that either you
> are not running multithreaded or vacation never goes down the path that has
> the barrier.
> Here's something that could help you debug: define some magic calls that
> just print a message and place them in vacation to see where it is and what
> it is doing. So, right in the barrier function, just put in the magic call
> that prints out how many threads are in the barrier by now. That will let
> you see whether or not barrier is ever invoked and how many threads are in
> the barrier. Don't put in printf, that won't work as well because the print
> doesn't make it to the terminal immediately whereas the magic call will
> print immediately.
> Polina
>
> On Sun, Oct 25, 2009 at 4:06 AM, ruzhu kao <kaoruzhu@xxxxxxxxx> wrote:
>>
>> Hi all:
>>     Recently I have modified STAMP-9.10 to make them run on LogTM-SE
>> (Simics 2.2.19 + GEMS 2.1). I test these binaries and collect some
>> stats file, all of them show me reasonable profile files except
>> vacation that its BARRIER_BREAKDOWN_CYCLE is zero which indicates
>> there must some mistakes on my modifications. However I use the same
>> lib to compile these applications and the execute them on the same
>> environment. I check the workload setup, and I believe I have obeyed
>> the rules on WISC' wiki. This problem drives me crazy. Have you ever
>> met this problem? If so, how to solve this problem.
>>   Another question is about cache warming up, I have test bayes
>> running on my checkpoint without cache warming up, it can generate
>> stats file so I assume both the magic breakpoints are set correctly.
>> Then I make a warm up checkpoint, when I run the same bayes, it can
>> load ruby but without out stats file even after it printed the output
>> message after the second magic breakpoint. Loading ruby which seems
>> the first magic breakpoint is ok, why the second magic breakpoint miss
>> its effecting.
>>
>>  I hope you can help me out. Thanks in advance.
>>
>>
>> Sincerely yours:
>> Ruzhu
>> _______________________________________________
>> 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.
>
>
>
_______________________________________________
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.