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? > -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
