From: Mark Wielaard <mjw@redhat.com>
To: Rajasekhar Duddu <rajduddu@linux.vnet.ibm.com>
Cc: systemtap@sources.redhat.com
Subject: Re: [PATCH V6] Tracepoint Tapset for Memory Subsystem
Date: Tue, 29 Dec 2009 21:36:00 -0000 [thread overview]
Message-ID: <1262122570.22922.32.camel@hermans.wildebeest.org> (raw)
In-Reply-To: <20091211183545.GA4643@rajduddu>
Hi Rajasekhar,
On Sat, 2009-12-12 at 00:05 +0530, Rajasekhar Duddu wrote:
> Changelog 3:
> Defined two macros for converting the GFP_FLAGS into string
> formats.
> Added k(ret)probe based fallback probes for all the
> Functions.
Sorry for the late feedback. I finally tested on an old 2.6.18 kernel
which didn't have the tracepoints defined. I made a couple of changes to
the fallback probes to make them work (a bit). I agree with Wenji that
having bytes_alloc be sometimes a long and sometimes a string is not
very helpful. So I made it a long always by setting it to the same value
as bytes_req. That isn't ideal, but better than having the type
mismatch. I couldn't find a good solution for the vm.kmalloc fallback,
since the function is always inlined, the return probe won't really work
(I pulled that test out of the other buildok/vm.tracepoints.stp to show
the rest does build now). Maybe someone knows a trick to get this
fallback to also work. But maybe we should just encourage people to
upgrade their kernel to one that has the tracepoints defined.
Cheers,
Mark
commit 11c015d84facc299ebcb12771ccda1975333a6bc
Author: Mark Wielaard <mjw@redhat.com>
Date: Tue Dec 29 21:05:55 2009 +0100
Fixup some memory tapset vm kernel function probe fallbacks.
Older kernels don't have all GFP constants defined, and the fallback
kernel function probe fallbacks don't have the same dwarf variable
names as the kernel trace point probes. So replace them with variables
that are available. bytes_alloc was sometimes a long and sometimes a
string, this caused scripts to fail depending on which alternative was
chosen for a particular kernel. So make it a long always.
This isn't a full solution since kmalloc is always inlined which makes
the kernel.function("kmalloc").return probe fail.
* tapset/memory.stp: Define __GFP_THISNODE, __GFP_RECLAIMABLE,
GFP_TEMPORARY, GFP_HIGHUSER_MOVABLE and GFP_THISNODE when not yet
defined.
(__vm.kmalloc.kp): Use $flags, not $gfp_flags. Set bytes_alloc equal
to bytes_req.
(__vm.kmem_cache_alloc.kp): Likewise. And use $cachep->buffer_size
for bytes_req.
(__vm.kmalloc_node.kp): Likewise.
(__vm.kmem_cache_alloc_node.kp): Likewise.
(__vm.kfree.kp): Use $ibjp for ptr, not $return.
(__vm.kmem_cache_free.kp): Likewise.
* testsuite/buildok/vm.tracepoints.stp: Move vm.kmalloc test to...
* testsuite/buildok/vm.tracepoints.kmalloc.stp: ... here.
prev parent reply other threads:[~2009-12-29 21:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-25 9:31 [PATCH V4] " Rajasekhar Duddu
2009-11-30 16:26 ` Frank Ch. Eigler
2009-12-04 12:09 ` [PATCH V5] " Rajasekhar Duddu
2009-12-07 2:52 ` Wenji Huang
2009-12-09 6:57 ` Rajasekhar Duddu
2009-12-11 18:36 ` [PATCH V6] " Rajasekhar Duddu
2009-12-21 11:46 ` Prerna Saxena
2009-12-21 21:49 ` Mark Wielaard
2009-12-22 17:02 ` Prerna Saxena
2009-12-29 21:36 ` Mark Wielaard [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1262122570.22922.32.camel@hermans.wildebeest.org \
--to=mjw@redhat.com \
--cc=rajduddu@linux.vnet.ibm.com \
--cc=systemtap@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).