Thread (10 messages) flat view 10 messages, 5 authors, 2021-10-25

Re: [PATCH V2] powerpc/perf: Enable PMU counters post partition migration if PMU is active

From: Athira Rajeev <hidden>
Date: 2021-10-25 20:58:10

On 21-Oct-2021, at 11:03 PM, Nathan Lynch [off-list ref] wrote:

Nicholas Piggin <npiggin@gmail.com <mailto:npiggin@gmail.com>> writes:
quoted
Excerpts from Athira Rajeev's message of July 11, 2021 10:25 pm:
quoted
During Live Partition Migration (LPM), it is observed that perf
counter values reports zero post migration completion. However
'perf stat' with workload continues to show counts post migration
since PMU gets disabled/enabled during sched switches. But incase
of system/cpu wide monitoring, zero counts were reported with 'perf
stat' after migration completion.

Example:
./perf stat -e r1001e -I 1000
          time             counts unit events
    1.001010437         22,137,414      r1001e
    2.002495447         15,455,821      r1001e
<<>> As seen in next below logs, the counter values shows zero
       after migration is completed.
<<>>
   86.142535370    129,392,333,440      r1001e
   87.144714617                  0      r1001e
   88.146526636                  0      r1001e
   89.148085029                  0      r1001e

Here PMU is enabled during start of perf session and counter
values are read at intervals. Counters are only disabled at the
end of session. The powerpc mobility code presently does not handle
disabling and enabling back of PMU counters during partition
migration. Also since the PMU register values are not saved/restored
during migration, PMU registers like Monitor Mode Control Register 0
(MMCR0), Monitor Mode Control Register 1 (MMCR1) will not contain
the value it was programmed with. Hence PMU counters will not be
enabled correctly post migration.

Fix this in mobility code by handling disabling and enabling of
PMU in all cpu's before and after migration. Patch introduces two
functions 'mobility_pmu_disable' and 'mobility_pmu_enable'.
mobility_pmu_disable() is called before the processor threads goes
to suspend state so as to disable the PMU counters. And disable is
done only if there are any active events running on that cpu.
mobility_pmu_enable() is called after the processor threads are
back online to enable back the PMU counters.

Since the performance Monitor counters ( PMCs) are not
saved/restored during LPM, results in PMC value being zero and the
'event->hw.prev_count' being non-zero value. This causes problem
Interesting. Are they defined to not be migrated, or may not be 
migrated?
PAPR may be silent on this... at least I haven't found anything yet. But
I'm not very familiar with perf counters.

How much assurance do we have that hardware events we've programmed on
the source can be reliably re-enabled on the destination, with the same
semantics? Aren't there some model-specific counters that don't make
sense to handle this way?

quoted
quoted
diff --git a/arch/powerpc/include/asm/rtas.h b/arch/powerpc/include/asm/rtas.h
index 9dc97d2..cea72d7 100644
--- a/arch/powerpc/include/asm/rtas.h
+++ b/arch/powerpc/include/asm/rtas.h
@@ -380,5 +380,13 @@ static inline void rtas_initialize(void) { }
static inline void read_24x7_sys_info(void) { }
#endif

+#ifdef CONFIG_PPC_PERF_CTRS
+void mobility_pmu_disable(void);
+void mobility_pmu_enable(void);
+#else
+static inline void mobility_pmu_disable(void) { }
+static inline void mobility_pmu_enable(void) { }
+#endif
+
#endif /* __KERNEL__ */
#endif /* _POWERPC_RTAS_H */
It's not implemented in rtas, maybe consider putting this into a perf 
header?
+1
Sure, I will move this to perf_event header file

Thanks
Athira
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help