From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11632 invoked by alias); 23 Apr 2007 21:05:27 -0000 Received: (qmail 11624 invoked by uid 22791); 23 Apr 2007 21:05:27 -0000 X-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_20,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; Mon, 23 Apr 2007 22:05:24 +0100 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 l3NL5MEC029638 for ; Mon, 23 Apr 2007 17:05:22 -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 l3NL5M5p025413 for ; Mon, 23 Apr 2007 17:05:22 -0400 Received: from [10.11.14.142] (vpn-14-142.rdu.redhat.com [10.11.14.142]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id l3NL5KYo026838 for ; Mon, 23 Apr 2007 17:05:21 -0400 Message-ID: <462D1F8B.4020607@redhat.com> Date: Mon, 23 Apr 2007 21:05:00 -0000 From: William Cohen User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: SystemTAP Subject: Tracking vm activity Content-Type: multipart/mixed; boundary="------------070107060605030203000103" X-Virus-Checked: Checked by ClamAV on sourceware.org 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-q2/txt/msg00116.txt.bz2 This is a multi-part message in MIME format. --------------070107060605030203000103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 941 Hi, I am playing around with getting information about page faults and I noticed that there is a probe alias for the entry for the pagefault code. However, there is no matching probe point for the return. It is useful to look at the return value to determine what kind of page fault occurred (major or minor). The attached patch provides a similar probe point for the return point. any comments on the patch? This would be useful for the following senario. A probe on vm.pagefault could get the address and a probe on vm.pagefault.return could get information how it was handled. The analysis could then do things like which addresses cause major page faults (real disk accesses). One could write out a log of the major page faults (and the mmap operations) and track which files caused the page faults. Probably don't want to walk through the mm structures when taking a page fault to determine which file it came from. -Will --------------070107060605030203000103 Content-Type: text/x-patch; name="pagefault_return.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pagefault_return.patch" Content-length: 595 Index: tapset/memory.stp =================================================================== RCS file: /cvs/systemtap/src/tapset/memory.stp,v retrieving revision 1.4 diff -U2 -u -r1.4 memory.stp --- tapset/memory.stp 7 Nov 2006 09:26:24 -0000 1.4 +++ tapset/memory.stp 21 Mar 2007 14:40:27 -0000 @@ -27,4 +27,10 @@ } +probe vm.pagefault.return = kernel.function( + %( kernel_v >= "2.6.13" %? "__handle_mm_fault" %: "handle_mm_fault" %) + ).return +{ +} + /* Return which node the given address belongs to in a NUMA system */ function addr_to_node:long(addr:long) /* pure */ --------------070107060605030203000103--