On Wed, Sep 10, 2014 at 8:08 PM, Gary Mohr <gary.m...@bull.com> wrote:

>  Hi Stephane, Vince,
>
>
>
> When I run these tests, I am running on a RHEL6 system which uses a kernel
> based on 2.6.32 but which has lots of features backported by redhat (like
> support for uncore and Haswell).  The tests are being run on a SNBEP system
> (family 6 model 45).
>
>
>
> I have run the perf command uncore tests again and discovered that even
> when I run the same test repeatedly, sometimes it will work (both events
> return counts) and sometimes it will fail (one or both events return
> errors).  And I think that I have now seen two system crashes while running
> these tests.  The attached file shows some of the test output if you are
> interested.
>
>
>
> I am beginning to believe that the kernel I am running could be
> responsible for this behavior.  So if either of you guys could rerun these
> tests on a newer kernel and tell me that all works fine, it would help to
> confirm my suspicions.  Of course if either or you know of any kernel
> commits that may have corrected a problem like this, please share I am very
> interested.
>
>
>
As I said, your cmdline worked for me. So I think your kernel is at fault.
Another thing you can
try is to have perf dump the perf_event_attr it is passing to make sure it
corresponds to what
you are trying to measure. On newer perf, you can do this with perf stat
-vv -e ......


>  Thanks
>
> Gary
>
>
>
>
>
> *From:* Stephane Eranian [mailto:eran...@googlemail.com]
> *Sent:* Tuesday, September 09, 2014 1:37 AM
> *To:* Vince Weaver
> *Cc:* Gary Mohr; Michel Brown; perfmon2-devel
> *Subject:* Re: [perfmon2] Error reporting when using invalid combination
> of umasks.
>
>
>
>
>
>
>
> On Mon, Sep 8, 2014 at 8:23 PM, Vince Weaver <vincent.wea...@maine.edu>
> wrote:
>
> On Tue, 9 Sep 2014, Gary Mohr wrote:
>
> > --- ls output removed ---
> >
> >  Performance counter stats for '/bin/ls':
> >
> >              5,625 uncore_cbox_0/event=0x35,umask=0xa/
>                   [26.27%]
> >    <not supported> uncore_cbox_0/event=0x35,umask=0x4a,filter_nid=0x1/
> >
> >        0.002038929 seconds time elapsed
> >
> >
> > So this behaved similar to PAPI/libpfm4.  The first event returned a
> count and the second event got an error.
> > Just for fun, I used the same events in the opposite order:
> >
> >
> > perf stat -a -e
> \{"uncore_cbox_0/event=0x35,umask=0x4a,filter_nid=0x1/","uncore_cbox_0/event=0x35,umask=0xa/"\}
> /bin/ls
> >
> > --- ls output removed ---
> >
> >  Performance counter stats for '/bin/ls':
> >
> >      <not counted> uncore_cbox_0/event=0x35,umask=0x4a,filter_nid=0x1/
> >    <not supported> uncore_cbox_0/event=0x35,umask=0xa/
> >
> >        0.002003219 seconds time elapsed
> >
> >
> > This caused both events to report an error.  This seems to me like a
> kernel problem.  I also tried using each event by itself and they both
> returned counts.  With PAPI/libpfm4 I believe that this test will return a
> count for the first event and an error on the second.
> > You implied that the { } 's may influence if or how events are grouped.
> So I tried the command again in the original order without the { }
> characters and got this:
> >
> >
> > perf stat -a -e
> "uncore_cbox_0/event=0x35,umask=0xa/","uncore_cbox_0/event=0x35,umask=0x4a,filter_nid=0x1/"
> /bin/ls
> >
> > --- ls output removed ---
> >
> >  Performance counter stats for '/bin/ls':
> >
> >             57,288 uncore_cbox_0/event=0x35,umask=0xa/
>                   [18.05%]
> >            158,292 uncore_cbox_0/event=0x35,umask=0x4a,filter_nid=0x1/
>                                   [ 3.07%]
> >
> >        0.001963151 seconds time elapsed
> >
> >
> > Both events give a count.  I have never seen this result with
> PAPI/libpfm4 but I have never tried them with grouping enabled when calling
> the kernel.
> >
> > In PAPI we turned grouping off so that the kernel would allow us to use
> events from different uncore pmu's at the same time.  I can try turning it
> back on and running these two events to see what happens.  If they work,
> maybe a better solution is to try a hybrid form of grouping.  We could
> create a different group for each uncore pmu and put all the events
> associated with a given pmu into that pmu's group.  We would then call the
> kernel once for each group rather than once for each event as we are doing
> now.
> >
> > Any idea if the kernel will let us play the game this way ??
>
> Interesting, I'll have to run some more tests on my Sandybridge-EP
> machine.
>
> What kernel are you running again?  I'm testing on a machine running 3.14
> so possibly there were scheduling bugs with older kernels that were fixed
> at some point.
>
> When running both with and without {} I get something like:
>
> Performance counter stats for 'system wide':
>
>                606      uncore_cbox_0/event=0x35,umask=0xa/
>                     [99.61%]
>                247      uncore_cbox_0/event=0x35,umask=0x4a,filter_nid=0x1/
>
>        0.000851895 seconds time elapsed
>
> Which makes it look like it's multiplexing the events in some sort of way
> I'm not really following, maybe to avoid a scheduling issue.
>
>
>
> It should not need to multiplex in this case. I believe the events are
> compatible.
>
>
>
> I'd like to see what is going on with the latest upstream kernel.
>
> There were some issues processing the filter in the uncore code, but not
> for SNBEP
>
> AFAIR.
>
>
>
>  Vince
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce.
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> perfmon2-devel mailing list
> perfmon2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
>
>
>
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Reply via email to