public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Adrian Hunter <adrian.hunter@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Andy Lutomirski <luto@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Andi Kleen <ak@linux.intel.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Joerg Roedel <joro@8bytes.org>, Jiri Olsa <jolsa@redhat.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org
Subject: Re: [PATCH V1 06/19] perf tools: Fix kernel_start for PTI on x86
Date: Wed, 16 May 2018 15:38:05 -0300	[thread overview]
Message-ID: <20180516183805.GD1230@kernel.org> (raw)
In-Reply-To: <e20ff118-953e-d118-b5ff-cae52c6ff284@intel.com>

Em Wed, May 16, 2018 at 09:16:57PM +0300, Adrian Hunter escreveu:
> On 05/16/2018 04:55 PM, Arnaldo Carvalho de Melo wrote:
> > Em Wed, May 16, 2018 at 04:45:41PM +0300, Adrian Hunter escreveu:
> >> On 16/05/18 16:00, Arnaldo Carvalho de Melo wrote:
> >>> 2303	bool machine__is(struct machine *machine, const char *arch)
> >>> 2304	{
> >>> 2305		return machine && machine->env && !strcmp(machine->env->arch, arch);
> >>> 2306	}
> >>> 2307	
> >>> 2308	int machine__get_kernel_start(struct machine *machine)
> >>> 2309	{
> >>> (gdb) p machine
> >>> $1 = (struct machine *) 0xc55548
> >>> (gdb) p machine->env
> >>> $2 = (struct perf_env *) 0xc06400 <perf_env>
> >>> (gdb) p machine-env->arch
> >>> No symbol "env" in current context.
> >>> (gdb) p machine->env->arch
> >>> $3 = 0x0
> >>> (gdb)
> >  
> >> If there is no perf_data then perf_session__new() uses perf_env but it seems
> >> perf_env.arch is not initialized.  Would it be OK to initialize
> >> perf_env.arch and perf_env.nr_cpus_avail?
> > 
> > I guess so, to make that always available, i.e. no perf.data? Those
> > should reflect the running machine environment.
> > 
> > So a preparatory patch that makes that the case would be good, I think.
> 
> How about this:
> 
> From: Adrian Hunter <adrian.hunter@intel.com>
> Date: Wed, 16 May 2018 19:58:19 +0300
> Subject: [PATCH] perf tools: Initialize perf_env.arch and
>  perf_env.nr_cpus_avail
> 
> Initialize perf_env.arch and perf_env.nr_cpus_avail so that they are
> available for tools to use, even for tools that are not processing a
> perf.data file.
> 
> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
>  tools/perf/perf.c     |  4 ++++
>  tools/perf/util/env.c | 36 ++++++++++++++++++++++++++++++++++++
>  tools/perf/util/env.h |  2 ++
>  3 files changed, 42 insertions(+)
> 
> diff --git a/tools/perf/perf.c b/tools/perf/perf.c
> index 20a08cb32332..03ec7a3b996b 100644
> --- a/tools/perf/perf.c
> +++ b/tools/perf/perf.c
> @@ -300,7 +300,11 @@ static int run_builtin(struct cmd_struct *p, int argc, const char **argv)
>  	commit_pager_choice();
>  
>  	perf_env__set_cmdline(&perf_env, argc, argv);
> +	status = perf_env__read_common(&perf_env);
> +	if (status < 0)
> +		goto cleanup;


But this is being done unconditionally, right? We already do _tons_ of
stuff at startup, I think this should be done when we actually need it,
if not done before, i.e. either make tools that need it and know it is
not read because they don't read a perf.data file (perf-top) read it
explicitely or use perf_env__arch(machine->env) where one is not sure it
is already read, and that would do the read.

- Arnaldo

  reply	other threads:[~2018-05-16 18:38 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-15 12:43 [PATCH V1 00/19] perf tools and x86 PTI entry trampolines Adrian Hunter
2018-05-15 12:43 ` [PATCH V1 01/19] kallsyms: Simplify update_iter_mod() Adrian Hunter
2018-05-15 12:43 ` [PATCH V1 02/19] kallsyms, x86: Export addresses of syscall trampolines Adrian Hunter
2018-05-15 12:43 ` [PATCH V1 03/19] x86: Add entry trampolines to kcore Adrian Hunter
2018-05-15 12:43 ` [PATCH V1 04/19] x86: kcore: Give entry trampolines all the same offset in kcore Adrian Hunter
2018-05-15 12:43 ` [PATCH V1 05/19] perf tools: Use the _stest symbol to identify the kernel map when loading kcore Adrian Hunter
2018-05-15 12:43 ` [PATCH V1 06/19] perf tools: Fix kernel_start for PTI on x86 Adrian Hunter
2018-05-16 13:00   ` Arnaldo Carvalho de Melo
2018-05-16 13:45     ` Adrian Hunter
2018-05-16 13:55       ` Arnaldo Carvalho de Melo
2018-05-16 18:16         ` Adrian Hunter
2018-05-16 18:38           ` Arnaldo Carvalho de Melo [this message]
2018-05-15 12:43 ` [PATCH V1 07/19] perf tools: Workaround missing maps for x86 PTI entry trampolines Adrian Hunter
2018-05-15 12:43 ` [PATCH V1 08/19] perf tools: Fix map_groups__split_kallsyms() for entry trampoline symbols Adrian Hunter
2018-05-15 12:43 ` [PATCH V1 09/19] perf tools: Allow for extra kernel maps Adrian Hunter
2018-05-15 12:43 ` [PATCH V1 10/19] perf tools: Create maps for x86 PTI entry trampolines Adrian Hunter
2018-05-16 11:06   ` Jiri Olsa
2018-05-16 11:37     ` Adrian Hunter
2018-05-15 12:43 ` [PATCH V1 11/19] perf tools: Synthesize and process mmap events " Adrian Hunter
2018-05-15 12:43 ` [PATCH V1 12/19] perf buildid-cache: kcore_copy: Keep phdr data in a list Adrian Hunter
2018-05-15 12:43 ` [PATCH V1 13/19] perf buildid-cache: kcore_copy: Keep a count of phdrs Adrian Hunter
2018-05-15 12:43 ` [PATCH V1 14/19] perf buildid-cache: kcore_copy: Calculate offset from phnum Adrian Hunter
2018-05-15 12:43 ` [PATCH V1 15/19] perf buildid-cache: kcore_copy: Layout sections Adrian Hunter
2018-05-15 12:43 ` [PATCH V1 16/19] perf buildid-cache: kcore_copy: Iterate phdrs Adrian Hunter
2018-05-15 12:43 ` [PATCH V1 17/19] perf buildid-cache: kcore_copy: Get rid of kernel_map Adrian Hunter
2018-05-15 12:43 ` [PATCH V1 18/19] perf buildid-cache: kcore_copy: Copy x86 PTI entry trampoline sections Adrian Hunter
2018-05-15 12:43 ` [PATCH V1 19/19] perf buildid-cache: kcore_copy: Amend the offset of sections that remap kernel text Adrian Hunter
2018-05-16 12:50 ` [PATCH V1 00/19] perf tools and x86 PTI entry trampolines Jiri Olsa

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=20180516183805.GD1230@kernel.org \
    --to=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jolsa@redhat.com \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --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