Looping in Mathieu at this time.
On Thu, Dec 03, 2020 at 02:39:41PM +0800, Leo Yan wrote: > Hi Will, > > [ + Mathieu ] > > On Tue, Dec 01, 2020 at 11:09:36PM +0000, Will Deacon wrote: > > On Tue, Dec 01, 2020 at 12:10:40PM +0800, Leo Yan wrote: > > > On Mon, Nov 30, 2020 at 04:46:51PM +0000, Will Deacon wrote: > > > > On Mon, Nov 30, 2020 at 06:24:54PM +0200, James Clark wrote: > > > > > Enable PID_IN_CONTEXTIDR by default when Arm SPE is enabled. > > > > > This flag is required to get PID data in the SPE trace. Without > > > > > it the perf tool will report 0 for PID which isn't very useful, > > > > > especially when doing system wide profiling or profiling > > > > > applications that fork. > > > > > > > > Can perf not figure out the pid some other way? (e.g. by tracing context > > > > switches and correlating that with the SPE data?). > > > > > > For perf 'per-thread' mode, we can use context switch trace event as > > > assisted info to select thread context. But for "system wide" mode and > > > "snapshot" mode in perf tool, since the trace data is continuous, I > > > think we cannot use context switch trace event to correlate the SPE > > > trace data. > > > > Is there no way to correlate them with something like CNTVCT? > > Good point. Yes, we can convert CNTVCT to system time; I read the > code in the perf's intel-pt.c and found the timestamp is used to > correlate the auxtrace heap. I think it's better to dig more for > detailed implementation. > > > > > Also, how does this work with pid namespaces? > > > > > > Here we are studying the implemetation of Intel-PT and Arm CoreSight. > > > > > > The context ID is stored into the hardware trace data when record; > > > afterwards when perf tool decodes the trace data and detects the > > > packet for context ID, it will select the machine's thread context in > > > perf [1]. Since the perf tool gathers all the threads infomation in > > > perf data file, based on the context ID, it can find the corresponding > > > thread pointer with function machine__find_thread() [2]. > > > > > > Since your question is for "pid namespace", to be honest, I don't know > > > how perf tool to handle any confliction for differrent processes share > > > the same PID, and I am not sure if you are asking CGroup related stuff > > > or not. If this cannot answer your question, please let me know. > > > > My point was that the pid value written to CONTEXTIDR is a global pid > > and does not take namespacing into account. If perf is run inside a pid > > namespace, it will therefore not work. > > Understand now. > > The perf events PERF_RECORD_ITRACE_START/PERF_RECORD_SWITCH/ > PERF_RECORD_SWITCH_CPU_WIDE can be used to set pid/tid in perf. So this > would be a safe way for perf tool running in pid namespace. > > Loop in Mathieu, this is a common issue for both Arm SPE and CoreSight > (IIRC, though CoreSight's timestamp is not strictly attaching to Arm arch > timer counter, the trend is to unify this for using arch timer > counter). > > I think James could continue to upstream a new patch by following your > suggestion for enabling PID_IN_CONTEXTIDR, eventually, it's a feature > for Arm SPE to record CONTEXTIDR in its packet. > > Your questions inspired me, thanks! > > Leo