From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20253 invoked by alias); 20 Oct 2006 14:28:27 -0000 Received: (qmail 20245 invoked by uid 22791); 20 Oct 2006 14:28:26 -0000 X-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 20 Oct 2006 14:28:19 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k9KESIhG006763; Fri, 20 Oct 2006 10:28:18 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id k9KESH9d013310; Fri, 20 Oct 2006 10:28:17 -0400 Received: from [172.16.59.108] (dhcp59-108.rdu.redhat.com [172.16.59.108]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k9KESHvO024189; Fri, 20 Oct 2006 10:28:17 -0400 Message-ID: <4538DD01.2080504@redhat.com> Date: Fri, 20 Oct 2006 14:28:00 -0000 From: William Cohen User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: david_list@boreham.org CC: Vara Prasad , SystemTap Subject: Re: user mode backtrace References: <4537E44C.6040604@boreham.org> <4537FD1A.9080607@us.ibm.com> <45380175.3080708@boreham.org> In-Reply-To: <45380175.3080708@boreham.org> 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/msg00216.txt.bz2 David Boreham wrote: > 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. The disk I/O schedules the reads and writes. It is unlikely that the matching user process is running when the physical read occurs. Would it be useful to look at the elapsed time between entry and exit time of the read system call and trigger recording of information if it is over some threshold? Would it make sense for the probing code to mark that userstack is needed and then record when the processor is about to return to userspace? The marking takes a fixed amount of time to do, so should be safe for probes. -Will