On Thu, Nov 5, 2015 at 7:27 AM, William Cohen <wco...@redhat.com> wrote: > On 11/05/2015 10:01 AM, Stephane Eranian wrote: >> On Thu, Nov 5, 2015 at 3:48 PM, William Cohen <wco...@redhat.com> wrote: >>> On 11/05/2015 12:11 AM, Stephane Eranian wrote: >>>> >>>> >>>> On Wed, Nov 4, 2015 at 9:06 AM, William Cohen <wco...@redhat.com >>>> <mailto:wco...@redhat.com>> wrote: >>>> >>>> On 11/03/2015 11:01 PM, Stephane Eranian wrote: >>>> > Will, >>>> > >>>> > On Tue, Nov 3, 2015 at 10:12 PM, William Cohen <wco...@redhat.com >>>> <mailto:wco...@redhat.com> <mailto:wco...@redhat.com >>>> <mailto:wco...@redhat.com>>> wrote: >>>> > >>>> > On 11/03/2015 01:41 PM, Stephane Eranian wrote: >>>> > > Will, >>>> > > >>>> > > Could you provide the list of events detected by libpfm4? >>>> > > You need to run as root: sudo examples/showevtinfo -L >>>> > > Clearly the ubo uncore event should not be processed as part >>>> of tracepoints. >>>> > >>>> > Hi Stephane, >>>> > >>>> > The count of the number of elements in the array was not be >>>> reset when the static array was being reset. Attached is a patch that >>>> addresses the problem. It allows the PAPI fmultiplex1 test to run >>>> correctly when the tracepoints are being read in multiple times. >>>> > >>>> > I don't understand why this patch fixes the problem. perf_nevents >>>> (perf_event_support.pme_count) >>>> > is statically initialized. By the time you get to pfm_perf_init() it >>>> still holds that initial value which is >>>> > what you are setting it. Why would that help? >>>> > >>>> > >>>> > -Will >>>> > >>>> > >>>> >>>> Hi Stephane, >>>> >>>> In the papi fmultiplex1.F test the initialization is being done >>>> multiple times. The initialization sets perf_pe to perf_static_events. >>>> However, when the test is run as root the array is cloned and the number >>>> of entries in the array is increased. The pme_count field in >>>> perf_event_support is changed when the additional tracepoints are added to >>>> the cloned array. The changes in the pme_count are caused by the >>>> "perf_nevents++" in the code. It is kind of hidden by the perf_nevents >>>> macro. You can see the changes to pme_count in gdb with a hardware watch >>>> point with the following gdb command: >>>> >>>> But pfm_inittialize() does not do the initialization twice if you call it >>>> twice. The initdone flag is set. And then last >>>> week, I added something else to cache the return value. So how do you get >>>> into a situation where the initialization >>>> is done multiple times. >>> >>> Hi Stephane, >>> >>> The papi git repository has pulled in the October 29 patch "cache >>> pfm_initialize() return value". The reason the initialization is being run >>> multiple times is because pfm_terminate() is being called at the end of >>> each test case and pfm_terminate() sets pfm_cfg.initdone = 0. Thus, when >>> pfm_initialized() is called for the next case is actually does all the >>> initialization code. This is why the resetting of pme_count field has an >>> effect. >>> >> >> Ok, I get it now! >> Then maybe a better solution is to ensure that the pmu_terminate() >> callbacks restore the pme_count to what it was initially. >> That applies to pfm_intel_x86_arch_terminate() and >> pfm_perf_terminate(). What do you think? > > Hi Stephane, > > I originally had the pme_count reset in pfm_perf_terminate, but moved it to > pfm_perf_init because it seemed to make more sense to pair it with the reset > of perf_pe to perf_static_events to keep the initialization together. > Grouping related initialization should probably stay close together rather > than being split between pfm_perf_init() and pfm_perf_terminate(). > Ok, then send mea patch that fixes this for both the perf and x86_arch PMUs in their init function and I will apply it today. Thanks for tracking this down.
------------------------------------------------------------------------------ _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
