mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: German Gomez <german.gomez@arm.com>
To: Leo Yan <leo.yan@linaro.org>, Namhyung Kim <namhyung@kernel.org>
Cc: James Clark <james.clark@arm.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Jiri Olsa <jolsa@redhat.com>, Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Andi Kleen <ak@linux.intel.com>, Ian Rogers <irogers@google.com>,
	Stephane Eranian <eranian@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>
Subject: Re: [RFC] perf arm-spe: Track task context switch for cpu-mode events
Date: Tue, 12 Oct 2021 12:07:45 +0100	[thread overview]
Message-ID: <8a1eafe3-d19e-40d6-f659-de0e9daa5877@arm.com> (raw)
In-Reply-To: <20211011142940.GB37383@leoy-ThinkPad-X240s>

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@arm.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

  reply	other threads:[~2021-10-12 11:07 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-16  0:17 Namhyung Kim
2021-09-16 13:54 ` Leo Yan
2021-09-16 21:01   ` Namhyung Kim
2021-09-23 14:23     ` Leo Yan
2021-09-23 16:01       ` Namhyung Kim
2021-09-30 18:47         ` Stephane Eranian
2021-10-01 10:44           ` James Clark
2021-10-01 18:22             ` Stephane Eranian
2021-10-04 15:19               ` Leo Yan
2021-09-30 15:08       ` James Clark
2021-10-04  6:26         ` Leo Yan
2021-10-05 10:06           ` German Gomez
2021-10-06  9:36             ` Leo Yan
2021-10-06 16:09               ` Namhyung Kim
2021-10-08 11:07                 ` German Gomez
2021-10-09  0:12                   ` Namhyung Kim
2021-10-11 13:58                     ` German Gomez
2021-10-11 14:29                       ` Leo Yan
2021-10-12 11:07                         ` German Gomez [this message]
2021-10-18 11:01                           ` German Gomez
2021-10-18 13:23                             ` Leo Yan
2021-10-19 12:21                               ` German Gomez
2021-10-29 10:51                                 ` German Gomez
2021-11-01 15:11                                   ` Leo Yan
2021-11-01 15:36                                     ` German Gomez
2021-11-01 15:42                                       ` German Gomez
2021-10-06 14:06             ` James Clark

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8a1eafe3-d19e-40d6-f659-de0e9daa5877@arm.com \
    --to=german.gomez@arm.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=ak@linux.intel.com \
    --cc=eranian@google.com \
    --cc=irogers@google.com \
    --cc=james.clark@arm.com \
    --cc=jolsa@redhat.com \
    --cc=leo.yan@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®