From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753769Ab2DTJis (ORCPT ); Fri, 20 Apr 2012 05:38:48 -0400 Received: from casper.infradead.org ([85.118.1.10]:43111 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750814Ab2DTJir (ORCPT ); Fri, 20 Apr 2012 05:38:47 -0400 Subject: Re: [RFC 1/2] kernel patch for dump user space stack tool From: Peter Zijlstra To: Yanmin Zhang Cc: Cong Wang , "Tu, Xiaobing" , Lin Ming , "akpm@linux-foundation.org" , "mingo@elte.hu" , "rusty@rustcorp.com.au" , "linux-kernel@vger.kernel.org" , "rostedt@goodmis.org" , "Zuo, Jiao" In-Reply-To: <1334812653.14538.29.camel@ymzhang.sh.intel.com> References: <4F8F8B9E.3040107@gmail.com> <1334812653.14538.29.camel@ymzhang.sh.intel.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 20 Apr 2012 11:38:39 +0200 Message-ID: <1334914719.2463.32.camel@laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.