From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <systemtap-return-1448-listarch-systemtap=sources.redhat.com@sources.redhat.com>
Received: (qmail 30801 invoked by alias); 5 Oct 2005 17:36:08 -0000
Mailing-List: contact systemtap-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:systemtap-subscribe@sources.redhat.com>
List-Post: <mailto:systemtap@sources.redhat.com>
List-Help: <mailto:systemtap-help@sources.redhat.com>, <http://sources.redhat.com/lists.html#faqs>
Sender: systemtap-owner@sources.redhat.com
Received: (qmail 30784 invoked by uid 22791); 5 Oct 2005 17:36:05 -0000
Subject: Re: pfaults.stp fix (for 2.6.13 and beyond)
From: Badari Pulavarty <pbadari@us.ibm.com>
To: William Cohen <wcohen@redhat.com>
Cc: systemtap@sources.redhat.com
In-Reply-To: <4343FC3D.1070604@redhat.com>
References: <1128525662.4754.59.camel@dyn9047017102.beaverton.ibm.com>
	 <4343FC3D.1070604@redhat.com>
Content-Type: text/plain
Date: Wed, 05 Oct 2005 17:36:00 -0000
Message-Id: <1128533722.4754.65.camel@dyn9047017102.beaverton.ibm.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
X-SW-Source: 2005-q4/txt/msg00008.txt.bz2

On Wed, 2005-10-05 at 12:15 -0400, William Cohen wrote:
> Badari Pulavarty wrote:
> > Hi,
> > 
> > handle_mm_fault() became a inline function now (2.6.13 & beyond). 
> > So pfaults.stp should use __handle_mm_fault() instead.
> > 
> > Thanks,
> > Badari
> > 
> > [root@elm3b23 systemtap.samples]# stap -g pfaults.stp
> > semantic error: no match for probe point
> >          while: resolving probe point kernel.function("handle_mm_fault")
> > semantic error: no match for probe point
> >          while: resolving probe point kernel.function
> > ("handle_mm_fault").return
> > Pass 2: analysis failed.  Try again with '-v' (verbose) option.
> 
> The number for the various types of faults will also need to be 
> adjusted. Looking at 2.6.13-1.1526 kernel used in FC4.
> 
> linux-2.6.13/include/linux/mm.h has:
> 
> #define VM_FAULT_OOM    0x00
> #define VM_FAULT_SIGBUS 0x01
> #define VM_FAULT_MINOR  0x02
> #define VM_FAULT_MAJOR  0x03
> 
> I noticed this because of the large number of major faults without any 
> minor faults recorded. However, using the numbers above I see values 
> that look more reasonable for minor faults, but I don't see any major 
> faults counted when I was playing around with this.
> 

Yes. I noticed that too. Is there a sane of handling these between
two kernel versions ? (like function name changes, #define changes, 
disappearing functions).

I tried doing,

#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,13)
probe kernel.function("handle_mm_fault") {
#else
probe kernel.function("__handle_mm_fault") {
#endif

But doesn't work.

Thanks,
Badari