From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: "Hunter, Adrian" <adrian.hunter@intel.com>
Cc: Leo Yan <leo.yan@linaro.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Borislav Petkov <bp@alien8.de>, "x86@kernel.org" <x86@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Mathieu Poirier <mathieu.poirier@linaro.org>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Mike Leach <mike.leach@linaro.org>,
"linux-perf-users@vger.kernel.org"
<linux-perf-users@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"coresight@lists.linaro.org" <coresight@lists.linaro.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v4 10/11] perf env: Set flag for kernel is 64-bit mode
Date: Wed, 14 Jul 2021 11:00:44 -0300 [thread overview]
Message-ID: <YO7uDIQYB9wduMd6@kernel.org> (raw)
In-Reply-To: <YO7t1UTrPh4TsiI9@kernel.org>
Em Wed, Jul 14, 2021 at 10:59:49AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Jul 13, 2021 at 05:31:03PM +0000, Hunter, Adrian escreveu:
> > > On Mon, Jul 12, 2021 at 03:14:35PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > Em Sun, Jul 11, 2021 at 06:41:04PM +0800, Leo Yan escreveu:
> > > > > +++ b/tools/perf/util/env.c
> > > > > @@ -11,6 +11,7 @@
> > > > > #include <stdlib.h>
> > > > > #include <string.h>
>
> > > > > +int kernel_is_64_bit;
> > > > > struct perf_env perf_env;
>
> > > > Why can't this be in 'struct perf_env'?
>
> > > Good question. I considered to add it in struct perf_env but finally I used this
> > > way; the reason is this variable "kernel_is_64_bit" is only used during
> > > recording phase for AUX ring buffer, and don't use it for report. So seems to
> > > me it's over complexity to add a new field and just wander if it's necessary to
> > > save this field as new feature in the perf header.
>
> > I think we store the arch, so if the "kernel_is_64_bit" calculation depends only on arch
> > then I guess we don't need a new feature at the moment.
>
> So, I wasn't suggesting to add this info to the perf.data file header,
> just to the in-memory 'struct perf_env'.
>
> And also we should avoid unconditionally initializing things that we may
> never need, please structure it as:
Oops, forgot these:
> static void perf_env__init_kernel_mode(struct perf_env *env)
> {
> const char *arch = perf_env__raw_arch(env);
>
> if (!strncmp(arch, "x86_64", 6) || !strncmp(arch, "aarch64", 7) ||
> !strncmp(arch, "arm64", 5) || !strncmp(arch, "mips64", 6) ||
> !strncmp(arch, "parisc64", 8) || !strncmp(arch, "riscv64", 7) ||
> !strncmp(arch, "s390x", 5) || !strncmp(arch, "sparc64", 7))
> kernel_is_64_bit = 1;
env->kernel_is_64_bit = 1;
> else
> kernel_is_64_bit = 0;
env->kernel_is_64_bit = 0;
> }
>
>
> void perf_env__init(struct perf_env *env)
> {
> ...
> env->kernel_is_64_bit = -1;
> ...
> }
>
> bool perf_env__kernel_is_64_bit(struct perf_env *env)
> {
> if (env->kernel_is_64_bit == -1)
> perf_env__init_kernel_mode(env);
>
> return env->kernel_is_64_bit;
> }
>
> One thing in my TODO is to crack down on the tons of initializations
> perf does unconditionally, last time I looked there are lots :-\
>
> - Arnaldo
>
> > > Combining the comment from Adrian in another email, I think it's good to add
> > > a new field "compat_mode" in the struct perf_env, and this field will be
> > > initialized in build-record.c. Currently we don't need to save this value into
> > > the perf file, if later we need to use this value for decoding phase, then we
> > > can add a new feature item to save "compat_mode"
> > > into the perf file's header.
>
> > > If you have any different idea, please let me know. Thanks!
--
- Arnaldo
next prev parent reply other threads:[~2021-07-14 14:00 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-11 10:40 [PATCH v4 00/11] perf: Refine barriers for AUX ring buffer Leo Yan
2021-07-11 10:40 ` [PATCH v4 01/11] perf/ring_buffer: Add comment for barriers on " Leo Yan
2021-07-11 10:40 ` [PATCH v4 02/11] coresight: tmc-etr: Add barrier after updating " Leo Yan
2021-07-12 10:40 ` Suzuki K Poulose
2021-07-12 10:54 ` Leo Yan
2021-07-11 10:40 ` [PATCH v4 03/11] coresight: tmc-etf: Add comment for store ordering Leo Yan
2021-07-13 12:56 ` Peter Zijlstra
2021-07-13 15:49 ` Leo Yan
2021-07-11 10:40 ` [PATCH v4 04/11] perf/x86: Add barrier after updating bts Leo Yan
2021-07-13 13:01 ` Peter Zijlstra
2021-07-11 10:40 ` [PATCH v4 05/11] perf auxtrace: Use WRITE_ONCE() for updating aux_tail Leo Yan
2021-07-11 10:41 ` [PATCH v4 06/11] perf auxtrace: Drop legacy __sync functions Leo Yan
2021-07-11 10:41 ` [PATCH v4 07/11] perf auxtrace: Remove auxtrace_mmap__read_snapshot_head() Leo Yan
2021-07-12 14:32 ` Adrian Hunter
2021-07-13 13:10 ` Leo Yan
2021-07-11 10:41 ` [PATCH v4 08/11] perf: Cleanup for HAVE_SYNC_COMPARE_AND_SWAP_SUPPORT Leo Yan
2021-07-11 10:41 ` [PATCH v4 09/11] tools: Remove feature-sync-compare-and-swap feature detection Leo Yan
2021-07-11 10:41 ` [PATCH v4 10/11] perf env: Set flag for kernel is 64-bit mode Leo Yan
2021-07-12 14:37 ` Adrian Hunter
2021-07-12 18:14 ` Arnaldo Carvalho de Melo
2021-07-13 15:09 ` Leo Yan
2021-07-13 17:31 ` Hunter, Adrian
2021-07-14 13:59 ` Arnaldo Carvalho de Melo
2021-07-14 14:00 ` Arnaldo Carvalho de Melo [this message]
2021-07-23 7:11 ` Leo Yan
2021-07-11 10:41 ` [PATCH v4 11/11] perf auxtrace: Add compat_auxtrace_mmap__{read_head|write_tail} Leo Yan
2021-07-12 14:44 ` Russell King (Oracle)
2021-07-13 15:46 ` Leo Yan
2021-07-13 16:14 ` Russell King (Oracle)
2021-07-13 18:13 ` Catalin Marinas
2021-07-14 8:40 ` Russell King (Oracle)
2021-07-23 7:23 ` Leo Yan
2021-07-13 7:07 ` Adrian Hunter
2021-07-13 15:48 ` 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=YO7uDIQYB9wduMd6@kernel.org \
--to=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=bp@alien8.de \
--cc=coresight@lists.linaro.org \
--cc=hpa@zytor.com \
--cc=jolsa@redhat.com \
--cc=leo.yan@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mathieu.poirier@linaro.org \
--cc=mike.leach@linaro.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=suzuki.poulose@arm.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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;
as well as URLs for NNTP newsgroup(s).