The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Leo Yan <leo.yan@arm.com>
To: James Clark <james.clark@linaro.org>,
	Adrian Hunter <adrian.hunter@intel.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Mike Leach <mike.leach@linaro.org>,
	coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, "Liang,
	Kan" <kan.liang@linux.intel.com>
Subject: Re: [PATCH v1 3/9] perf auxtrace: Refactor auxtrace__evsel_is_auxtrace()
Date: Fri, 9 Aug 2024 11:57:26 +0100	[thread overview]
Message-ID: <3e3b38d1-5170-44ce-b1ba-e9599cceee95@arm.com> (raw)
In-Reply-To: <8258c91a-ab6c-42f0-a77c-dea52201deec@linaro.org>

On 8/9/24 11:08, James Clark wrote:

[...]

> On 08/08/2024 1:58 pm, Adrian Hunter wrote:
>> On 6/08/24 23:41, Leo Yan wrote:
>>> The auxtrace__evsel_is_auxtrace() function invokes the callback
>>> .evsel_is_auxtrace() to check if an event is an AUX trace. In the
>>> low-level code, every AUX trace module provides its callback to
>>> compare the PMU type.
>>>
>>> This commit refactors auxtrace__evsel_is_auxtrace() by simply
>>> calling evsel__is_aux_event() rather than using the callback function.
>>> As a result, the callback .evsel_is_auxtrace() is no longer needed, so
>>> the definition and implementations are removed.
>>
>> evsel__is_aux_event() assumes it is on the target machine e.g.
>> being called from perf record.  It indirectly reads from sysfs
>> to find PMUs, which will not necessarily be the same a different
>> machine.
>>
>> For example, what happens if a perf data file from one arch is
>> being processed on a machine from another arch.
> 
> I think this does go a bit wrong. If I open an SPE file on x86 it finds
> the intel_pt PMU which both have the same type number. But because
> that's also an auxtrace one it appears to work.

Yes, anyway, I missed the cross report case and this patch will break it.

A event attribute should contain info to indicate the event is an AUX event.
This would be better than inquiry every AUX module. I checked the attribute,
there have no attribute field can be use to indicate a event is AUX event.
A relevant field 'aux_output' is used to generate AUX trace rather than
events, which is not set for AUX events.

Can we add a new field 'auxtrace' into the structure perf_event_attr? By using
this way, the event will track the state rather than stored in PMU.

For next step, I will pick the first two patches in this series and merge them
into the multiple AUX events support patch set. This can allow us to firstly
resolve the multiple AUX event issue.

If we agree the refactoring for 'auxtrace' attribute, then I will use a separate
patch set to address it.

Thanks,
Leo
  

  reply	other threads:[~2024-08-09 10:57 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-06 20:41 [PATCH v1 0/9] perf auxtrace: Refactor with evsel__is_aux_event() Leo Yan
2024-08-06 20:41 ` [PATCH v1 1/9] perf auxtrace: Use evsel__is_aux_event() for checking AUX event Leo Yan
2024-08-09  7:55   ` Adrian Hunter
2024-08-06 20:41 ` [PATCH v1 2/9] perf auxtrace: Remove unused 'pmu' pointer from struct auxtrace_record Leo Yan
2024-08-09  8:02   ` Adrian Hunter
2024-08-28 21:16     ` Arnaldo Carvalho de Melo
2024-08-30  7:32       ` Leo Yan
2024-08-06 20:41 ` [PATCH v1 3/9] perf auxtrace: Refactor auxtrace__evsel_is_auxtrace() Leo Yan
2024-08-08 12:58   ` Adrian Hunter
2024-08-09 10:08     ` James Clark
2024-08-09 10:57       ` Leo Yan [this message]
2024-08-06 20:41 ` [PATCH v1 4/9] perf arm-spe: Remove the 'pmu_type' field Leo Yan
2024-08-06 20:41 ` [PATCH v1 5/9] perf cs-etm: " Leo Yan
2024-08-06 20:41 ` [PATCH v1 6/9] perf hisi-ptt: Remove the unused " Leo Yan
2024-08-06 20:41 ` [PATCH v1 7/9] perf intel-bts: Remove the " Leo Yan
2024-08-06 20:41 ` [PATCH v1 8/9] perf intel-pt: " Leo Yan
2024-08-06 20:41 ` [PATCH v1 9/9] perf s390-cpumsf: Remove the unused " Leo Yan

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=3e3b38d1-5170-44ce-b1ba-e9599cceee95@arm.com \
    --to=leo.yan@arm.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=coresight@lists.linaro.org \
    --cc=irogers@google.com \
    --cc=james.clark@linaro.org \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mike.leach@linaro.org \
    --cc=namhyung@kernel.org \
    --cc=suzuki.poulose@arm.com \
    /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