From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4452 invoked by alias); 19 Oct 2006 22:51:36 -0000 Received: (qmail 4443 invoked by uid 22791); 19 Oct 2006 22:51:35 -0000 X-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from skunk.mtbrook.bozemanpass.com (HELO skunk.mtbrook.bozemanpass.com) (69.145.82.195) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 19 Oct 2006 22:51:33 +0000 Received: from [69.145.82.218] (unknown [69.145.82.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by skunk.mtbrook.bozemanpass.com (Postfix) with ESMTP id B0F585583C9; Thu, 19 Oct 2006 15:51:31 -0700 (PDT) Message-ID: <45380175.3080708@boreham.org> Date: Thu, 19 Oct 2006 22:51:00 -0000 From: David Boreham Reply-To: david_list@boreham.org User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vara Prasad CC: SystemTap Subject: Re: user mode backtrace References: <4537E44C.6040604@boreham.org> <4537FD1A.9080607@us.ibm.com> In-Reply-To: <4537FD1A.9080607@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q4/txt/msg00197.txt.bz2 Vara Prasad wrote: > If i read your above message correctly you would like to put probes in > the kernel but you want to get a full stack which includes kernel mode > stack and as well as user mode stack, correct. ack > David, if you want to put probes in the user space itself and do back > trace we are working on user space probing patch that will let you > see the stack just in the application space only. We may be able to > give some thing for you to play within couple of weeks if you are > interested in user space probing. I'm not sure if this would work. It depends on whether I would need to identify the processes subject to probing in advance. The application spawns processes left and right, many of which are sort-lived. If I could place a probe in the glibc layer above the system calls that might work, but said probes would need to magically apply to any process that called that code. Is that the feature you have in mind ? But even so, I can imagine cases where it would still be useful to probe in the kernel but show user stack : e.g. I probe physical read from disk because I am not interested in reads served from filesystem cache. But I'd like to find out where the read calls that hit non-cached data are coming from in the application. Hope that makes sense. > My next question to you is we are looking to put good load on the > system while running probes, is this filesystem application is > something that you can share and it is easy for us to run outside of > your environment. If this is an application that you can not share > outside can you help us run this application while putting lots of > probes touching various parts of the system. We can give you scripts, > if you like, that will place probes in many parts of the system or > specifically in the areas this application touches the most. Please > let us know. The application is not supersecret. In fact in binary form it can be downloaded from a public web site. I have been loading it with an open source benchmark tool. So it would be possible for someone else to reproduce my setup. To see source you'd need to wait for the application to be open source'ed, which it will be soon but not right now. For now however I want to be a little cautious about the details of what I'm working on. Let me go find out how much I am able to share...