From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26960 invoked by alias); 2 Aug 2007 19:10:49 -0000 Received: (qmail 26911 invoked by uid 22791); 2 Aug 2007 19:10:47 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,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; Thu, 02 Aug 2007 19:10:43 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l72JAfqs031150 for ; Thu, 2 Aug 2007 15:10:41 -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 l72JAeJS021794 for ; Thu, 2 Aug 2007 15:10:40 -0400 Received: from [10.11.231.220] (dhcp231-220.rdu.redhat.com [10.11.231.220]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id l72JAepU023693 for ; Thu, 2 Aug 2007 15:10:40 -0400 Message-ID: <46B22C2A.1070002@redhat.com> Date: Thu, 02 Aug 2007 19:31:00 -0000 From: William Cohen User-Agent: Thunderbird 1.5.0.12 (X11/20070719) MIME-Version: 1.0 To: SystemTAP Subject: oprofile's mechanism to get file path information 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-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2007-q3/txt/msg00234.txt.bz2 There was some discussion at today's SystemTap meeting on getting the file path information for VFS tapset. The problem is that the functions in getting the path require some locks, and in general want to avoid getting locks when in a probe. It was mentioned that OProfile has a mechanism to get file path information (dcookies). OProfile's mechanism may not be entirely appropriate, but it have some similar issues. OProfile has a interrupt mechanisum that does the actual sampling. On x86_64 and i386 machines this is done as a non-maskable interrupt (NMI). As a result what can be done in the interrupt context is very limited. The interrupt mechanism just records the context that the interrupt occurred in, the linear address of the program counter, and the performance counter that caused the sample. OProfile records this information in per processor circular queues. This is done to eliminate the need for any locks. The linear address is of limited use because linear address is very ephemeral, different programs may map the same shared library to different locations. OProfile converts the linear address into a file and an offset into the file. This conversion happens when the data from the per processor buffers is collected into a system-wide buffer. Having arbitrary length strings in the buffer sent into user space is awkward. OProfile uses the dcookie mechanism to use fixed size integer numbers for the file path. The daemon in userspace can make a systemcall to convert the number back into a string. This makes the data format much more compact. It doesn't need to pass all large strings around; the user-space daemon only needs to do the dcookie lookup if it hasn't seen the dcookie value before. This user-space code in oprofile/daemon/opd_cookie.c does the operation. The kernel side of the code is in sys_lookup_dcookie, in linux/fs/dcookies.c. There is some code in linux/driver/oprofile/buffer_sync.c that is converting that linear address into a filename and offset. There is a dcookie_mutex for the dcookie stuff, so there is still some locking. However, for oprofile this locking happens when the the buffers are being read out (less time critical) or in the user-space is trying to get a string name rather than when the sample is actually being collected. Maybe some of the approach used in dcookies would be useful for VFS path names. -Will