public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
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.


      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).