This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH v3] Tracepoint Tapset for Memory Subsystem
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