Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750728AbWC1JsU (ORCPT ); Tue, 28 Mar 2006 04:48:20 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750737AbWC1JsU (ORCPT ); Tue, 28 Mar 2006 04:48:20 -0500 Received: from mx2.suse.de ([195.135.220.15]:63363 "EHLO mx2.suse.de") by vger.kernel.org with ESMTP id S1750728AbWC1JsT (ORCPT ); Tue, 28 Mar 2006 04:48:19 -0500 From: Andi Kleen To: Richard J Moore Subject: Re: RFC - Approaches to user-space probes Date: Tue, 28 Mar 2006 11:47:57 +0200 User-Agent: KMail/1.9.1 Cc: Arjan van de Ven , Andrew Morton , davem@davemloft.net, Christoph Hellwig , linux-kernel@vger.kernel.org, Nick Piggin , prasanna@in.ibm.com, suparna@in.ibm.com, "Theodore Ts'o" References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603281147.59382.ak@suse.de> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1719 Lines: 40 On Tuesday 28 March 2006 11:42, Richard J Moore wrote: > 1) ptrace is orientated to debugging a specific process tree and a > nominated debug process. Having it operate on arbitrary process would > require kernel extensions to achieve that but would also have a major > impact on performance if each event were to result in a context switch to > the debugger process. You can attach it to any pid The problem is just finding new processes when they are created. And when you trace all it will be quite inefficient. > > 2) ptrace operates by privatizing memory via COW, but kprobes doesn't. The > probes are fixed-up when a page is brought into memory by using an alias > r/w virtual address. Using existing the ptrace mechanism across all, or > most, processes could have a significant affect on swapfile and paging > rate. And that has to be bad news when investigating performance and race > conditions problems. The problem with ptrace is also that it is quite heavyweight - you have to take over all signals at least etc. Some lighter weight probing mechanism for user space would be probably a good idea. > If we want to make life easier for debugging the types of problems > indicated above, then it's seems very reasonable to ask whether ptrace can > be extended to use the (user) kprobes mechanism. It's a mistery to me why people hate ioctl and like ptrace. ptrace already is far too complex and ugly. Clean new calls would be probably preferable. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/