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(). -Will ------------------------------------------------------------------------------ _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
