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

[ruzhu kao <kaoruzhu@xxxxxxxxx>]

Hi Polina:
   You are right. I have dumped debug message and grep BARRIER in this
file, It shows the program does not BEGIN BARRIER by
ruby_magic_call(29).
   I'll insert some magic_call to test how it happened and let you
know my progress.
   Thanks for your help.

Sincerely your:
Ruzhu


2009/10/26 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.
>>
>
>
> _______________________________________________
> 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.
>
>
>