All of lore.kernel.org
 help / color / mirror / Atom feed
From: Byungchul Park <byungchul.park@lge.com>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
	Ingo Molnar <mingo@kernel.org>,
	peterz@infradead.org, linux-kernel@vger.kernel.org,
	walken@google.com, Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [PATCH 1/2] x86/dumpstack: Optimize save_stack_trace
Date: Tue, 19 Jul 2016 09:08:01 +0900	[thread overview]
Message-ID: <20160719000801.GS2279@X58A-UD3R> (raw)
In-Reply-To: <20160718130910.vmyvadh5arurxptv@treble>

On Mon, Jul 18, 2016 at 08:09:10AM -0500, Josh Poimboeuf wrote:
> > > > There are several different users of save_stack_trace() in the kernel, we can't
> > > > be sure that all of them are interested in dropping those guesses.
> > > > 
> > > > So I'd rather advocate in favour of a new seperate helper.
> > > 
> > > So how about we change save_stack_trace() to use print_context_stack()
> > > for CONFIG_FRAME_POINTER=n and print_context_stack_bp() for
> > > CONFIG_FRAME_POINTER=y?  That would preserve the existing behavior, no?
> > 
> > Even if CONFIG_FRAME_POINTER=y, someone may want to guess, doesn't they?
> 
> For CONFIG_FRAME_POINTER=y, the guesses are ignored by
> __save_stack_address() and only the reliable addresses are saved.

Indeed. I was confused.

> We shouldn't change that behavior, unless you actually know of a caller
> who wants the guesses.  And even then the "guess" variation should be
> named accordingly to make it clear that it's not a "reliable" stack
> trace, even though frame pointers are enabled.

My question was caused by being confused. I agree with you.

> 
> -- 
> Josh

  reply	other threads:[~2016-07-19  0:10 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-04 10:27 [PATCH 1/2] x86/dumpstack: Optimize save_stack_trace Byungchul Park
2016-07-04 10:27 ` [PATCH 2/2] x86/dumpstack: Add save_stack_trace_norm() Byungchul Park
2016-07-07 10:17 ` [PATCH 1/2] x86/dumpstack: Optimize save_stack_trace Byungchul Park
2016-07-08 10:08   ` Ingo Molnar
2016-07-08 14:29     ` Josh Poimboeuf
2016-07-08 14:48       ` Ingo Molnar
2016-07-08 15:02       ` Frederic Weisbecker
2016-07-08 15:22         ` Josh Poimboeuf
2016-07-18  3:14           ` Byungchul Park
2016-07-18 13:09             ` Josh Poimboeuf
2016-07-19  0:08               ` Byungchul Park [this message]
2016-07-18  2:42         ` Byungchul Park
2016-07-08 15:07     ` Frederic Weisbecker
2016-07-18  2:37     ` Byungchul Park
2016-07-08 14:08 ` Josh Poimboeuf
2016-07-08 14:44 ` Frederic Weisbecker
2016-07-18  3:25   ` Byungchul Park

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=20160719000801.GS2279@X58A-UD3R \
    --to=byungchul.park@lge.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=fweisbec@gmail.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=walken@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.