Re: [perfmon2] Deterministic events

[stephane e. <er...@go...>]

On Fri, Feb 12, 2010 at 5:57 PM, heechul Yun <hee...@gm...> wrote:
>
>
> On Fri, Feb 12, 2010 at 10:37 AM, stephane eranian <er...@go...>
> wrote:
>>
>> On Fri, Feb 12, 2010 at 5:17 PM, heechul Yun <hee...@gm...>
>> wrote:
>> > I'm experimenting performance counter to find deterministic events.
>> >
>> > I originally thought that the number of retired instructions will be the
>> > same for every run of the program with the same input. However, it was
>> > not.
>> >
>> > The following is the result with the 'task' example provided in libpfm4
>> > package.
>> >
>> >  ./task -e "inst_retired" gcc
>> > gcc: no input files
>> >              1252403 inst_retired
>> >
>> >  ./task -e "inst_retired" gcc
>> > gcc: no input files
>> >              1252405 inst_retired
>> >
>> >
>> > As you can see above, they are different for each run. I only enabled
>> > 'user'
>> > mode counting to exclude any perturbation.
>> >
>> I would not call this a major perturbation, it's more like noise.
>> One way this might be introduced is when you are interrupted very
>> near the kernel/user boundary, for instance as you are about to
>> leave the kernel. I would not worry about those. It will be more
>> significant as you add more events or as you compete with
>> other users on the system.
>>
> Interestingly, "inst_retired:stores" seems to give deterministic number.
> /task -e "inst_retired:stores" gcc
> gcc: no input files
>               108856 inst_retired:stores
> /task -e "inst_retired:stores" gcc
> gcc: no input files
>               108856 inst_retired:stores
> /task -e "inst_retired:stores" gcc
> gcc: no input files
>               108856 inst_retired:stores
>
Is it because stores happen much less frequently and they are, therefore,
less likely to be impacted by external events (such as interruts, instruction
retries).

> As you said, however, If I used multiple events, it starts to give largely
> non-deterministic numbers.
> ./task -e "inst_retired:stores,inst_retired:loads" gcc
> gcc: no input files
>                95890 inst_retired:stores (scaled from 56.57% of time)
>               321715 inst_retired:loads (scaled from 43.43% of time)

Here you see the effect of multiplexing. I suspect you are running with
a very recent kernel which has the NMI watchdog stealing one counter.
Thus you only have one counter left to monitor two events, thus the
close to 50% to each.

This illustrates the competition I was talking about. With automatic
multiplexing, you are not measuring all the time. The count you
get in the end is scaled, thus it can be quite approximative depending
on the workload.


>  ./task -e "inst_retired:stores,inst_retired:loads" gcc
> gcc: no input files
>                47850 inst_retired:stores (scaled from 33.86% of time)
>               363727 inst_retired:loads (scaled from 66.14% of time)
> The question are,
> 1) why "inst_retired:stores" is deterministic -- if it is true?
> 2) if there are more than two events or users to use performance counter, is
> it impossible to guarantee reliable (or deterministic) number ?
> Best
> Heechul
>>
>> >         fds[0].hw.exclude_kernel = 1;
>> >         fds[0].hw.exclude_idle = 1;
>> >         fds[0].hw.exclude_hv = 1;
>> >
>> >
>> > What is the reason of this unexpected non-determinism?
>> >
>> > Best Regards,
>> >
>> > Heechul
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > SOLARIS 10 is the OS for Data Centers - provides features such as
>> > DTrace,
>> > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
>> > http://p.sf.net/sfu/solaris-dev2dev
>> > _______________________________________________
>> > perfmon2-devel mailing list
>> > per...@li...
>> > https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
>> >
>> >
>
>