[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1335229007.14538.43.camel@ymzhang.sh.intel.com>
Date: Tue, 24 Apr 2012 08:56:47 +0800
From: Yanmin Zhang <yanmin_zhang@...ux.intel.com>
To: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: Cong Wang <xiyou.wangcong@...il.com>,
"Tu, Xiaobing" <xiaobing.tu@...el.com>,
Lin Ming <mlin@...pku.edu.cn>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"mingo@...e.hu" <mingo@...e.hu>,
"rusty@...tcorp.com.au" <rusty@...tcorp.com.au>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
"Zuo, Jiao" <jiao.zuo@...el.com>
Subject: Re: [RFC 1/2] kernel patch for dump user space stack tool
On Fri, 2012-04-20 at 11:38 +0200, Peter Zijlstra wrote:
> 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..
Real developers, real debuggers care it. End users don't care it.
>
> > 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.
Not true for my patch. We did many experiments. Originally, we used
the similar method like pstack based on ptrace and found it's
very slow to do so when getting all the stacks of all processes
when system reports an issue.
Anyway, thanks for taking your time to look at it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists