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. -Will > > watch perf_event_support.pme_count > > When done the pme_count field no longer has the original count of > elements in perf_static_events. If the initialization is run again without > this patch, the number of entries in the array is listed number of entries in > the static array AND the tracepoint entries. The cloning process for the > reinitialization gets things very wrong copying past the end of the > perf_static_events array and the test crashes. The supplied patch ensures > that if the initialization is run multiple times that it will get the correct > number of entries in the static array. > > This problem may not have been noticeable because it only occurs when the > initialization is being done as root and the initialization is being done > multiple times. > > Yes, tracepoints are only accessible to root. But again, how do you end up > calling the init multiple times and > pfm_initialize() does not return immediately. > ------------------------------------------------------------------------------ _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
