All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>,
	Pekka Enberg <penberg@cs.helsinki.fi>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Dipankar Sarma <dipankar@in.ibm.com>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] kmemtrace: Use tracepoints instead of markers.
Date: Fri, 2 Jan 2009 16:48:05 -0500	[thread overview]
Message-ID: <20090102214805.GA26654@Krystal> (raw)
In-Reply-To: <20081230140232.GG10635@localhost>

* Eduard - Gabriel Munteanu (eduard.munteanu@linux360.ro) wrote:
> On Tue, Dec 30, 2008 at 10:40:17AM -0200, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Dec 30, 2008 at 09:41:28AM +0200, Eduard - Gabriel Munteanu escreveu:
> > > kmemtrace now uses tracepoints instead of markers. We no longer need to
> > > use format specifiers. Also dropped kmemtrace_mark_alloc_node(), since
> > > it's easy to pass -1 as the NUMA node without providing a needless and
> > > long-named variant of the same function.
> > > 
> > > Signed-off-by: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
> > > diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h
> > > index 7555ce9..fe3cea2 100644
> > > --- a/include/linux/slab_def.h
> > > +++ b/include/linux/slab_def.h
> > > @@ -76,8 +76,8 @@ found:
> > >  
> > >  		ret = kmem_cache_alloc_notrace(cachep, flags);
> > >  
> > > -		kmemtrace_mark_alloc(KMEMTRACE_TYPE_KMALLOC, _THIS_IP_, ret,
> > > -				     size, slab_buffer_size(cachep), flags);
> > > +		trace_kmalloc(_THIS_IP_, ret,
> > > +			      size, slab_buffer_size(cachep), flags, -1);
> > 
> > Is there a way for a tracepoint to get the caller without having to pass
> > it explicitely?
> > 
> > - Arnaldo
> 
> It might be possible, but for correctness DEFINE_TRACE() should use
> __always_inline instead of inline.
> 

Yes, we could (and maybe should) use __always_inline there. Hrm, which
which tree to you work ? You probably mean DECLARE_TRACE() rather than
DEFINE_TRACE() ?

I just went over your patch again. it uses the old DEFINE_TRACE() API.
You should get the latest tracepoints which have DECLARE_TRACE() (for
trace/kmemtrace.h) and then a DEFINE_TRACE() in a .c.  Ah I see, you
work on 2.6.28. You should work on top of -tip, which has this new API.
Using the tracepoints present in 2.6.28 will not let you do only a
single definition of the tracepoint structure and it will lead to waste
of kernel memory by defining multiple instances of tracepoint structures
(one for each trace_*() use, so one per kmalloc()). The
Documentation/tracepoints.txt file is updated accordingly.


> But it is quite pointless. Sometimes we need _RET_IP_, sometimes
> _THIS_IP_ and sometimes a parameter we've been passed. That's because we
> want the IP of the caller, so it depends on whether this slab function
> is __always_inline, non-inlined or deeply nested within other functions
> (which can be as well __always_inline or non-inlined).
> 

Hrm ? In the case we just want

  trace_kmalloc(_THIS_IP, ......);

If we have __always_inline for the trace_*() declaration, isn't it the
same to just do this in the probe ?

void probe_kmalloc(......)
{
  ... _RET_IP_ ...;

}

This would remove a parameter from the stack created from the
instrumentation site, which is always good.

Mathieu

> 
> 	Eduard
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

  reply	other threads:[~2009-01-02 21:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-30  7:41 [PATCH 0/2] kmemtrace over tracepoints (resubmit) Eduard - Gabriel Munteanu
2008-12-30  7:41 ` [PATCH 1/2] RCU: Don't include unnecessary headers, allow kmemtrace w/ tracepoints Eduard - Gabriel Munteanu
2008-12-30  7:49   ` Ingo Molnar
2008-12-30  7:53     ` Ingo Molnar
2008-12-30  8:14       ` Eduard - Gabriel Munteanu
2008-12-30  8:21         ` Ingo Molnar
2008-12-30  7:41 ` [PATCH 2/2] kmemtrace: Use tracepoints instead of markers Eduard - Gabriel Munteanu
2008-12-30  7:50   ` Pekka Enberg
2008-12-30 12:40   ` Arnaldo Carvalho de Melo
2008-12-30 14:02     ` Eduard - Gabriel Munteanu
2009-01-02 21:48       ` Mathieu Desnoyers [this message]
2009-01-02 22:38         ` Eduard - Gabriel Munteanu
2009-01-02 23:32           ` Mathieu Desnoyers
2008-12-31  3:56 ` [PATCH 0/2] kmemtrace over tracepoints (resubmit) Paul E. McKenney

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=20090102214805.GA26654@Krystal \
    --to=mathieu.desnoyers@polymtl.ca \
    --cc=acme@redhat.com \
    --cc=adobriyan@gmail.com \
    --cc=dipankar@in.ibm.com \
    --cc=eduard.munteanu@linux360.ro \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=penberg@cs.helsinki.fi \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.