From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25736 invoked by alias); 14 Oct 2009 08:32:19 -0000 Received: (qmail 25725 invoked by uid 22791); 14 Oct 2009 08:32:18 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from e28smtp08.in.ibm.com (HELO e28smtp08.in.ibm.com) (59.145.155.8) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 14 Oct 2009 08:32:15 +0000 Received: from d28relay01.in.ibm.com (d28relay01.in.ibm.com [9.184.220.58]) by e28smtp08.in.ibm.com (8.14.3/8.13.1) with ESMTP id n9E8KXgp032732 for ; Wed, 14 Oct 2009 13:50:33 +0530 Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65]) by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9E8W6un2400338 for ; Wed, 14 Oct 2009 14:02:06 +0530 Received: from d28av03.in.ibm.com (loopback [127.0.0.1]) by d28av03.in.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n9E8W68O011930 for ; Wed, 14 Oct 2009 19:32:06 +1100 Received: from localhost ([9.124.33.39]) by d28av03.in.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n9E8W6hE011927; Wed, 14 Oct 2009 19:32:06 +1100 Date: Wed, 14 Oct 2009 08:32:00 -0000 From: Rajasekhar Duddu To: "Frank Ch. Eigler" Cc: systemtap@sources.redhat.com Subject: Re: [PATCH v3] Tracepoint Tapset for Memory Subsystem Message-ID: <20091014083205.GB6105@rajduddu> References: <4AB94A1B.4090801@redhat.com> <20090924180817.GA9698@rajduddu> <4ABD3B2B.4020107@redhat.com> <20090930101156.GA3792@rajduddu> <20091002151344.GA9516@rajduddu> <20091007130728.GA6574@rajduddu> <20091009170805.GA7769@rajduddu> <20091009173806.GA3061@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091009173806.GA3061@redhat.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 2009-q4/txt/msg00163.txt.bz2 On Fri, Oct 09, 2009 at 01:38:06PM -0400, Frank Ch. Eigler wrote: > Hi - > > On Fri, Oct 09, 2009 at 10:38:05PM +0530, Rajasekhar Duddu wrote: > > [...] > > > > Fallback kprobe is not available for other memory functions because > > > > the variables exported by them are will be modified. > > > > > > Could you elaborate? Do you mean that the same values may not be > > > available from a kprobe context? > > > Yes, the same values may not be available from a kprobe > > context, for example if we take "ret" variable as it is populated mid-way in > > the function and it is also the return value of a function which can > > be captured only by a return probe. But by a return probe we cannot > > capture the formal parameters of the memory function. > > Actually, we often can. $variables accessed in .function().return context > are exactly snapshots of the incoming actual arguments. > > So for example the trace_kmalloc() case, we could have a > k(ret)probes-based fallback based upon inspection of the sources, > and unwinding through the "__always_inline" stuff: > > probe __vm.kmalloc.kp = kernel.function("__kmalloc").return { > name = "kmalloc" > call_size = 0 > caller_function = "" > bytes_req = $size > bytes_alloc = bytes_req # unavailable > gfp_flags = gfp_flag_str($flags) > ptr = $return > } > > Based on CONFIG_NUMA (which we can now express preprocessor > conditionals on), there may be a _node variant, plus _track_caller > variants. All this can be expressed with some effort. > > > - FChE Hi Frank, sure , I will try to have the kprobe based probes with all possible parameters exported in my next patch. Thanks -- Rajasekhar Duddu (rajduddu@linux.vnet.ibm.com), Linux on System z - CSVT, IBM LTC, Bangalore.