From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16962 invoked by alias); 9 Oct 2009 17:38:14 -0000 Received: (qmail 16953 invoked by uid 22791); 9 Oct 2009 17:38:13 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 09 Oct 2009 17:38:09 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n99Hc7NT009184 for ; Fri, 9 Oct 2009 13:38:07 -0400 Received: from fche.csb (vpn-226-18.phx2.redhat.com [10.3.226.18]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n99Hc7Pn019401; Fri, 9 Oct 2009 13:38:07 -0400 Received: by fche.csb (Postfix, from userid 2569) id BCED95810F; Fri, 9 Oct 2009 13:38:06 -0400 (EDT) Date: Fri, 09 Oct 2009 17:38:00 -0000 From: "Frank Ch. Eigler" To: Rajasekhar Duddu Cc: systemtap@sources.redhat.com Subject: Re: [PATCH v3] Tracepoint Tapset for Memory Subsystem Message-ID: <20091009173806.GA3061@redhat.com> References: <4AB94A1B.4090801@redhat.com> <20090924180817.GA9698@rajduddu> <4ABD3B2B.4020107@redhat.com> <20090930101156.GA3792@rajduddu> <20091002151344.GA9516@rajduddu> <20091007130728.GA6574@rajduddu> <20091009170805.GA7769@rajduddu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091009170805.GA7769@rajduddu> User-Agent: Mutt/1.4.2.2i 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/msg00110.txt.bz2 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