Re: [PATCH v3] Tracepoint Tapset for Memory Subsystem

[Rajasekhar Duddu <rajduddu@linux.vnet.ibm.com>]

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.