LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>
To: Alexey Budankov <alexey.budankov@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>, Andi Kleen <ak@linux.intel.com>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4] perf record: collect user registers set jointly with dwarf stacks
Date: Thu, 30 May 2019 15:04:28 -0300	[thread overview]
Message-ID: <20190530180428.GA3711@kernel.org> (raw)
In-Reply-To: <dd70a760-aab5-cc65-5e6a-3a0340a4466f@linux.intel.com>

Em Thu, May 30, 2019 at 07:24:57PM +0300, Alexey Budankov escreveu:
> 
> On 30.05.2019 16:13, Arnaldo Carvalho de Melo wrote:
> > Em Thu, May 30, 2019 at 11:24:49AM +0300, Alexey Budankov escreveu:
> >> On 29.05.2019 22:25, Arnaldo Carvalho de Melo wrote:
> >>> Em Wed, May 29, 2019 at 05:30:49PM +0300, Alexey Budankov escreveu:
> >> <SNIP>
> >>>> +++ b/tools/perf/util/evsel.c
> >>>> +#define DWARF_REGS_MASK ((1ULL << PERF_REG_IP) | \
> >>>> +			 (1ULL << PERF_REG_SP))
> >>>> +
> >>>>  static void __perf_evsel__config_callchain(struct perf_evsel *evsel,
> >>>>  					   struct record_opts *opts,
> >>>>  					   struct callchain_param *param)
> >>>> @@ -702,7 +705,13 @@ static void __perf_evsel__config_callchain(struct perf_evsel *evsel,
> >>>>  		if (!function) {
> >>>>  			perf_evsel__set_sample_bit(evsel, REGS_USER);
> >>>>  			perf_evsel__set_sample_bit(evsel, STACK_USER);
> >>>> -			attr->sample_regs_user |= PERF_REGS_MASK;
> >>>> +			if (opts->sample_user_regs) {
> >>>
> >>> Where are you checking that opts->sample_user_regs doesn't have either
> >>> IP or SP?
> >>
> >> Sure. The the intention was to avoid such a complication, merge two 
> >> masks and provide explicit warning that the resulting mask is extended.
> > 
> > s/is/may be/g
> >  
> >> If you still see the checking and auto detection of the exact mask 
> >> extension as essential it can be implemented.
> > 
> > perf, tracing, systems internals, etc are super complicated, full of
> > details, the more precise we can make the messages, the better.
> >  
> >>> So, __perf_evsel__config_callchain its the routine that sets up the
> >>> attr->sample_regs_user when callchains are asked for, and what was it
> >>> doing? Asking for _all_ user regs, right?
> >>>
> >>> I.e. what you're saying is that when --callgraph-dwarf is asked for,
> >>> then only IP and BP are needed, and we should stop doing that, so that
> >>> would be a first patch, if that is the case. I.e. a patch that doesn't
> >>> even mention opts->sample_user_regs.
> >>>
> >>> Then, a second patch would fix the opt->sample_user_regs request clash
> >>> with --callgraph dwarf, i.e. it would do something like:
> >>>
> >>> 	      if ((opts->sample_regs_user & DWARF_REGS_MASK) != DWARF_REGS_MASK) {
> >>> 	      		char * ip = (opts->sample_regs_user & (1ULL << PERF_REG_IP)) ? NULL : "IP",
> >>> 	      		     * sp = (opts->sample_regs_user & (1ULL << PERF_REG_SP)) ? NULL : "SP",
> >>> 			     * all = (!ip && !sp) ?  "s" : "";
> >>>
> >>> 			pr_warning("WARNING: specified --user-regs register set doesn't include register%s "
> >>> 				   "needed by also specified --call-graph=dwarf, auto adding %s%s%s register%s.\n",
> >>> 				   all, ip, all : ", " : "", sp, all);
> >>> 		}
> >>>
> >>> This if and only if all the registers that are needed to do DWARF
> >>> unwinding are just IP and BP, which doesn't look like its true, since
> >>> when no --user_regs is set (i.e. opts->user_regs is not set) then we
> >>> continue asking for PERF_REGS_MASK...
> >>>
> >>> Can you check where I'm missing something?
> >>
> >> 1.  -g call-graph dwarf,K                         full_regs
> >> 2.  --user-regs=user_regs                         user_regs
> >> 3.  -g call-graph dwarf,K --user-regs=user_regs	  user_regs + dwarf_regs
> >>
> >> The default behavior stays the same for cases 1, 2 above.
> >> For case 3 register set becomes the one asked using --user_regs option.
> >> If the option value misses IP or SP or the both then they are explicitly
> >> added to the option value and a warning message mentioning the exact 
> >> added registers is provided.
> >  
> >>> Jiri DWARF unwind uses just IP and SP? Looking at
> >>> tools/perf/util/unwind-libunwind-local.c's access_reg() I don't think
> >>> so, right?
> >  
> >> If you ask me, AFAIK, DWARF unwind rules sometimes can refer additional 
> >> general purpose registers for frames boundaries calculation.
> > 
> > :-) So that DWARF_REGS is misleading, should be something like
> > DWARF_MINIMAL_REGS, as we may need other registers, so the original code
> > was correct, right?
> 
> Right. Actually came to the same conclusion with the same naming for IP,SP mask :)
> 
> > 
> > After all if the user asks for both --call-graph dwarf and --user-regs,
> > then probably we should require --force? I.e. the message then would be:
> > 
> > "
> > WARNING: The use of --call-graph=dwarf may require all the user
> > registers, specifying a subset with --user-regs may render DWARF
> > unwinding unreliable, please use --force if you're sure that the subset
> > specified via --user-regs is enough for your specific use case.
> > "
> > 
> > And then plain refuse, if the user _really_ wants it, then we have
> > --force/-f for those cases.
> > 
> > Does this sound better?
> 
> If --user-regs is specified jointly with --call-graph dwarf option then
> --user-regs already serves as the --force and, IMHO, a warning does the best.
 
> The ideal solution, I could imagine, is to also dynamically calculate regs 
> set extension and provide it in the warning, but it is only for two registers.
> 
> So, if --call-graph dwarf --user-regs=A,B,C are specified jointly then
> "
> WARNING: The use of --call-graph=dwarf may require all the user registers, 
> specifying a subset with --user-regs may render DWARF unwinding unreliable,
> so the minimal registers set (IP, SP) is explicitly forced.
> "

I think with this wording and the renaming of DWARF_REGS to
DWARF_MINIMAL_REGS it should be enough.

- Arnaldo

  reply	other threads:[~2019-05-30 18:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-29 14:30 Alexey Budankov
2019-05-29 19:25 ` Arnaldo Carvalho de Melo
2019-05-30  8:24   ` Alexey Budankov
2019-05-30 13:13     ` Arnaldo Carvalho de Melo
2019-05-30 16:24       ` Alexey Budankov
2019-05-30 18:04         ` Arnaldo Carvalho de Melo [this message]
2019-05-30 18:15           ` Alexey Budankov
  -- strict thread matches above, loose matches on Subject: below --
2019-05-23 11:20 Alexey Budankov

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=20190530180428.GA3711@kernel.org \
    --to=arnaldo.melo@gmail.com \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=alexey.budankov@linux.intel.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --subject='Re: [PATCH v4] perf record: collect user registers set jointly with dwarf stacks' \
    /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

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).