From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30366 invoked by alias); 20 Oct 2006 14:50:14 -0000 Received: (qmail 30351 invoked by uid 22791); 20 Oct 2006 14:50:14 -0000 X-Spam-Status: No, hits=-2.5 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; Fri, 20 Oct 2006 14:50:03 +0000 Received: from [69.145.82.253] (unknown [69.145.82.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by skunk.mtbrook.bozemanpass.com (Postfix) with ESMTP id CB81D5582B1; Fri, 20 Oct 2006 07:50:00 -0700 (PDT) Message-ID: <4538E217.7050505@boreham.org> Date: Fri, 20 Oct 2006 14:50:00 -0000 From: David Boreham User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: William Cohen CC: Vara Prasad , SystemTap Subject: Re: user mode backtrace References: <4537E44C.6040604@boreham.org> <4537FD1A.9080607@us.ibm.com> <45380175.3080708@boreham.org> <4538DD01.2080504@redhat.com> In-Reply-To: <4538DD01.2080504@redhat.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/msg00218.txt.bz2 > The disk I/O schedules the reads and writes. It is unlikely that the > matching user process is running when the physical read occurs. Can I clarify the problem here ? : the user process isn't running because it's been put to sleep waiting on I/O that is done in the context of another thread (or whatever we call that animal in the Linux kernel) , or is this when read-ahead is being done on the file, at the behest of the kernel, with no corresponding user process read() call having been issued yet ? (apologies my knowledge of present-day linux kernel details is rather patchy). > 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? Possibly. I wouldn't want to get too hung up on this specific example -- I thought it up off the top of my head. The point I was trying to make is that probing in userland in glibc may not do everything that's required because sometimes one is interested in events that are only visible inside the kernel. Physical I/O was just the first one that I could think of. I suppose a kernel mutex being busy might be another case. > 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. Yes, that sounds like a good way to do it.