Re: [PATCH v3] Tracepoint Tapset for Memory Subsystem

["Frank Ch. Eigler" <fche@redhat.com>]

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