[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211011142940.GB37383@leoy-ThinkPad-X240s>
Date: Mon, 11 Oct 2021 22:29:40 +0800
From: Leo Yan <leo.yan@...aro.org>
To: German Gomez <german.gomez@....com>
Cc: Namhyung Kim <namhyung@...nel.org>,
James Clark <james.clark@....com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Jiri Olsa <jolsa@...hat.com>, Ingo Molnar <mingo@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
LKML <linux-kernel@...r.kernel.org>,
Andi Kleen <ak@...ux.intel.com>,
Ian Rogers <irogers@...gle.com>,
Stephane Eranian <eranian@...gle.com>,
Adrian Hunter <adrian.hunter@...el.com>
Subject: Re: [RFC] perf arm-spe: Track task context switch for cpu-mode events
Hi German,
On Mon, Oct 11, 2021 at 02:58:40PM +0100, German Gomez wrote:
> Hi Namhyung,
>
> On 09/10/2021 01:12, Namhyung Kim wrote:
>
> > Hi German,
> >
> > On Fri, Oct 8, 2021 at 4:08 AM German Gomez <german.gomez@....com> wrote:
> >
> > [...]
> >
> > I think we should use context-switch even for kernel samples, but
> > only if the context packets are not available.
> >
> > Thanks,
> > Namhyung
>
> I think I agree with that you say. If --switch-events is not enabled by
> default like you mention, an user could opt-in to using the fallback if
> there's no better option for kernel tracing yet.
Actually I took time to try to find some way to enable switch events
conditionally. As Namhyung suggested, we can enable the switch events
in the perf tool (should do this in arm_spe_recording_options()), I am
just wandering if perf tool can enable switch event only when it runs
in the non-root namespace. I looked the code util/namespaces.c but
still fail to find any approach to confirm the perf is running in
the root namespace... anyway, this is not critical for this work.
Welcome if anyone has idea for this.
> @Leo, what are your thoughts on this? Perhaps adding a warning message
> to tell the user to please enable context packets, otherwise the results
> will have workload-dependant inaccuracies, could be a good enough
> compromise?
Yeah, this is exactly what I think. It's good to give a warning so
users have knowledge for the potential inaccuracies.
Thanks,
Leo
Powered by blists - more mailing lists