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