[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8a1eafe3-d19e-40d6-f659-de0e9daa5877@arm.com>
Date: Tue, 12 Oct 2021 12:07:45 +0100
From: German Gomez <german.gomez@....com>
To: Leo Yan <leo.yan@...aro.org>, Namhyung Kim <namhyung@...nel.org>
Cc: 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, Leo and Namhyung,
I want to make sure I'm on the same page as you regarding this topic.
On 11/10/2021 15:29, Leo Yan wrote:
> 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.
Do you think we should use them also when tracing outside of the root
namespace? I'm no sure if we are considering the driver patch to disable
context packets in non-root ns from earlier.
>> [...]
>> 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.
Thanks, Leo. We'll let you know if we come up with something too.
>
>> @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
If we are not considering patching the driver at this stage, so we allow
hardware tracing on non-root namespaces. I think we could proceed like
this:
- For userspace, always use context-switch events as they are
accurate and consistent with namespaces.
- For kernel tracing, if context packets are enabled, use them, but
warn the user that the PIDs correspond to the root namespace.
- Otherwise, use context-switch events and warn the user of the time
inaccuracies.
Later, if the driver is patched to disable context packets outside the
root namespace, kernel tracing could fall back to using context-switch
events and warn the user with a single message about the time
inaccuracies.
If we are aligned, we could collect your feedback and share an updated
patch that considers the warnings.
Many thanks
Best regards
Powered by blists - more mailing lists