From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Yanmin Zhang <yanmin_zhang@linux.intel.com>
Cc: Cong Wang <xiyou.wangcong@gmail.com>,
"Tu, Xiaobing" <xiaobing.tu@intel.com>,
Lin Ming <mlin@ss.pku.edu.cn>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"mingo@elte.hu" <mingo@elte.hu>,
"rusty@rustcorp.com.au" <rusty@rustcorp.com.au>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"rostedt@goodmis.org" <rostedt@goodmis.org>,
"Zuo, Jiao" <jiao.zuo@intel.com>
Subject: Re: [RFC 1/2] kernel patch for dump user space stack tool
Date: Fri, 20 Apr 2012 11:38:39 +0200 [thread overview]
Message-ID: <1334914719.2463.32.camel@laptop> (raw)
In-Reply-To: <1334812653.14538.29.camel@ymzhang.sh.intel.com>
On Thu, 2012-04-19 at 13:17 +0800, Yanmin Zhang wrote:
> Although not checking the source codes of pstack (sorry, I'm busy in debugging
> many critical issues), I think pstack is based on ptrace interface, which means:
> 1) It need traps into system for many times to collect call frames of one
> task.
> 2) It need send signal to the ptraced process to stop it. Such behavior
> might have some impact if the ptraced process also processes many signals.
Yeah, but who cares.. its debugging stuff..
> 3) The data parsing to get symbols might not be split from data collection.
> I mean, it collects call frames of one process, then parses it; then collects the 2nd
> task's. If there are many processes, it couldn't collect the data just at the monitor
> time point.
This is equally true for your silly patch.
next prev parent reply other threads:[~2012-04-20 9:38 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-17 14:37 [RFC 1/2] kernel patch for dump user space stack tool Tu, Xiaobing
2012-04-19 3:50 ` Cong Wang
2012-04-19 5:17 ` Yanmin Zhang
2012-04-19 6:13 ` Cong Wang
2012-04-19 6:28 ` Yanmin Zhang
2012-04-20 9:38 ` Peter Zijlstra [this message]
2012-04-24 0:56 ` Yanmin Zhang
2012-04-20 9:54 ` Peter Zijlstra
2012-04-24 2:19 ` Yanmin Zhang
-- strict thread matches above, loose matches on Subject: below --
2012-04-11 8:07 Tu, Xiaobing
2012-04-17 4:43 ` Lin Ming
2012-04-17 14:38 ` Tu, Xiaobing
2012-04-20 9:44 ` Peter Zijlstra
2012-04-24 1:30 ` Yanmin Zhang
2012-04-24 10:10 ` Peter Zijlstra
2012-04-25 2:58 ` Yanmin Zhang
2012-04-24 10:11 ` Peter Zijlstra
2012-04-25 2:44 ` Yanmin Zhang
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=1334914719.2463.32.camel@laptop \
--to=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=jiao.zuo@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mlin@ss.pku.edu.cn \
--cc=rostedt@goodmis.org \
--cc=rusty@rustcorp.com.au \
--cc=xiaobing.tu@intel.com \
--cc=xiyou.wangcong@gmail.com \
--cc=yanmin_zhang@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox