All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Tejun Heo <tj@kernel.org>
Cc: axboe@kernel.dk, mingo@redhat.com, rostedt@goodmis.org,
	teravest@google.com, slavapestov@google.com, ctalbott@google.com,
	dhsharp@google.com, linux-kernel@vger.kernel.org,
	winget@google.com, namhyung@gmail.com,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH 8/9] stacktrace: implement save_stack_trace_quick()
Date: Tue, 17 Jan 2012 03:22:31 +0100	[thread overview]
Message-ID: <20120117022227.GD24200@somewhere.redhat.com> (raw)
In-Reply-To: <20120111163826.GC26832@google.com>

On Wed, Jan 11, 2012 at 08:38:26AM -0800, Tejun Heo wrote:
> Hello, Frederic.
> 
> On Wed, Jan 11, 2012 at 05:26:44PM +0100, Frederic Weisbecker wrote:
> > On Tue, Jan 10, 2012 at 10:28:25AM -0800, Tejun Heo wrote:
> > > Implement save_stack_trace_quick() which only considers the usual
> > > contexts (ie. thread and irq) and doesn't handle links between
> > > different contexts - if %current is in irq context, only backtrace in
> > > the irq stack is considered.
> > 
> > The thing I don't like is the duplication that involves not only on
> > stack unwinding but also on the safety checks.
> 
> I'm not entirely convinced that this is necessary or we can just add
> more features to the existing backtrace facility (and maybe make that
> more efficient) and be done with it.

Yeah probably we can do that.

> 
> > > This is subset of dump_trace() done in much simpler way.  It's
> > > intended to be used in hot paths where the overhead of dump_trace()
> > > can be too heavy.
> > 
> > Is it? Have you found a measurable impact (outside the fact you record only
> > one stack).
> 
> As I wrote in the head message, I haven't done comparative test yet
> but in the preliminary tests the CPU overhead against memory backed
> device is quite visible (roughly ~20%), so I expect it to matter.
> Note that testing against memory backed device is actually relevant,
> on faster SSDs, CPU is already a bottleneck.
> 
> It would be best if we can extend the existing one to cover all the
> cases with acceptable overhead.  I needed to write this minimal
> version anyway for comparison so it's posted together but no matter
> how it turns out switching them isn't difficult.

Right. So there are two major differences that may affect performances
between save_stack_trace() and save_stack_trace_quick():

- save_stack_trace() does a full walk through the stack, but it rejects
unreliable entries. So to begin with, it should use print_context_stack_bp()
that does a frame pointer walk only (in CONFIG_FRAME_POINTER case).

- It links between stacks. Doing the ->stack() that returns a value should
help in this regard.

- And dump_stack() does various more checks, perhaps we can simplify
it a bit.

  parent reply	other threads:[~2012-01-17  2:22 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-10 18:28 [RFC PATCHSET take#2] ioblame: IO tracer with origin tracking Tejun Heo
2012-01-10 18:28 ` [PATCH 1/9] block: abstract disk iteration into disk_iter Tejun Heo
2012-01-10 18:28 ` [PATCH 2/9] block: block_bio_complete tracepoint was missing Tejun Heo
2012-01-11 17:25   ` Steven Rostedt
2012-01-11 17:30     ` Tejun Heo
2012-01-12  0:24       ` Namhyung Kim
2012-01-10 18:28 ` [PATCH 3/9] block: add @req to bio_{front|back}_merge tracepoints Tejun Heo
2012-01-10 18:28 ` [PATCH 4/9] writeback: move struct wb_writeback_work to writeback.h Tejun Heo
2012-01-10 18:28 ` [PATCH 5/9] writeback: add more tracepoints Tejun Heo
2012-01-10 18:28 ` [PATCH 6/9] block: add block_touch_buffer tracepoint Tejun Heo
2012-01-11 17:42   ` Steven Rostedt
2012-01-11 17:58     ` Tejun Heo
2012-01-10 18:28 ` [PATCH 7/9] vfs: add fcheck tracepoint Tejun Heo
2012-01-10 18:28 ` [PATCH 8/9] stacktrace: implement save_stack_trace_quick() Tejun Heo
2012-01-11 16:26   ` Frederic Weisbecker
2012-01-11 16:38     ` Tejun Heo
2012-01-11 17:37       ` Tejun Heo
2012-01-17  2:22       ` Frederic Weisbecker [this message]
2012-01-10 18:28 ` [PATCH 9/9] block, trace: implement ioblame - IO tracer with origin tracking Tejun Heo
2012-01-11  0:25   ` Chanho Park
2012-01-11  1:04     ` Tejun Heo
2012-01-11  1:32   ` [PATCH RESEND " Tejun Heo
2012-01-11  6:15     ` Namhyung Kim
2012-01-11 17:06       ` Tejun Heo
2012-01-12  1:05         ` Namhyung Kim
2012-01-12  1:14           ` Tejun Heo
2012-01-12  1:35             ` Namhyung Kim
2012-01-12  1:37               ` Tejun Heo
2012-01-12  1:40                 ` Namhyung Kim
2012-01-12  1:41                 ` Namhyung Kim
2012-01-12  1:44                   ` Tejun Heo
2012-01-12  2:19                     ` Namhyung Kim
2012-01-12  2:24                       ` Tejun Heo
2012-01-11 18:08     ` Tejun Heo
2012-01-11 14:40 ` [RFC PATCHSET take#2] ioblame: " Frederic Weisbecker
2012-01-11 17:02   ` Tejun Heo
2012-01-11 22:45     ` David Sharp

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=20120117022227.GD24200@somewhere.redhat.com \
    --to=fweisbec@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=ctalbott@google.com \
    --cc=dhsharp@google.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@gmail.com \
    --cc=rostedt@goodmis.org \
    --cc=slavapestov@google.com \
    --cc=teravest@google.com \
    --cc=tj@kernel.org \
    --cc=winget@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.