public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>,
	Dipankar Sarma <dipankar@in.ibm.com>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] kmemtrace: Use tracepoints instead of markers.
Date: Sat, 3 Jan 2009 01:01:17 +0200	[thread overview]
Message-ID: <20090102230116.GB5235@localhost> (raw)
In-Reply-To: <20090102205345.GB25473@Krystal>

On Fri, Jan 02, 2009 at 03:53:45PM -0500, Mathieu Desnoyers wrote:
> * Eduard - Gabriel Munteanu (eduard.munteanu@linux360.ro) wrote:
> >  
> > -#ifdef CONFIG_KMEMTRACE
> > -
> >  extern void kmemtrace_init(void);
> >  
> > -static inline void kmemtrace_mark_alloc_node(enum kmemtrace_type_id type_id,
> 
> Why do you need the enum kmemtrace_type_id type_id exactly ? Can you
> remove this parameter by adding more specific tracepoints ?
> 

Already done and moved that enum into the .c file. I've resubmitted the
whole thing (2 patches instead of 3). I'll provide an URL if you didn't get
those e-mails.

> > diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h
> > index 7555ce9..e5a8b60 100644
> > --- a/include/linux/slab_def.h
> > +++ b/include/linux/slab_def.h
> > @@ -76,8 +76,9 @@ found:
> >  
> >  		ret = kmem_cache_alloc_notrace(cachep, flags);
> >  
> > -		kmemtrace_mark_alloc(KMEMTRACE_TYPE_KMALLOC, _THIS_IP_, ret,
> > -				     size, slab_buffer_size(cachep), flags);
> > +		trace_kmemtrace_alloc(KMEMTRACE_TYPE_KMALLOC, _THIS_IP_, ret,
> > +				      size, slab_buffer_size(cachep),
> 
> You'll probably want to give "cachep" as parameter and do the
> slab_buffer_size(cachep) within the probe to remove unneeded code from
> the caller site.
> 

Hmm, I don't see how this could be an improvement. Slab code hackers are
supposed to see this and keep kmemtrace in line with slab internals.
Moving this away only makes things more awkward.

Besides, having a probe for each allocator and each function hardly
makes any sense.

Anyway, one could argue for an inline within slab code to handle such
internals, which does make more sense.

> > +				      flags, -1);
> >  
> >  		return ret;
> >  	}
> > @@ -134,9 +135,9 @@ found:
> >  
> >  		ret = kmem_cache_alloc_node_notrace(cachep, flags, node);
> >  
> > -		kmemtrace_mark_alloc_node(KMEMTRACE_TYPE_KMALLOC, _THIS_IP_,
> > -					  ret, size, slab_buffer_size(cachep),
> > -					  flags, node);
> > +		trace_kmemtrace_alloc(KMEMTRACE_TYPE_KMALLOC, _THIS_IP_,
> > +				      ret, size, slab_buffer_size(cachep),
> > +				      flags, node);
> >  
> >  		return ret;
> >  	}
> > diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
> > index dc28432..ce69c68 100644
> > --- a/include/linux/slub_def.h
> > +++ b/include/linux/slub_def.h
> > @@ -220,8 +220,8 @@ static __always_inline void *kmalloc_large(size_t size, gfp_t flags)
> >  	unsigned int order = get_order(size);
> >  	void *ret = (void *) __get_free_pages(flags | __GFP_COMP, order);
> >  
> > -	kmemtrace_mark_alloc(KMEMTRACE_TYPE_KMALLOC, _THIS_IP_, ret,
> > -			     size, PAGE_SIZE << order, flags);
> > +	trace_kmemtrace_alloc(KMEMTRACE_TYPE_KMALLOC, _THIS_IP_, ret,
> > +			      size, PAGE_SIZE << order, flags, -1);
> 
> Same here for order.

Same goes here.

> Why do you need to pass -1 ? Can you have a more specific tracepoint
> instead ?
>

I've noticed probe functions tend to have really long names. -1 is just
very convenient, we could make it typo-proof by taking all negative values as
meaning "same node" in userspace, or clamp / warn about it in probes. Anyway,
I've seen SLOB does it in its inlines, e.g. kmem_cache_alloc() calls
kmem_cache_alloc_node(..., -1).

> >  
> >  	return ret;
> >  }
> > @@ -242,9 +242,9 @@ static __always_inline void *kmalloc(size_t size, gfp_t flags)
> >  
> >  			ret = kmem_cache_alloc_notrace(s, flags);
> >  
> > -			kmemtrace_mark_alloc(KMEMTRACE_TYPE_KMALLOC,
> > -					     _THIS_IP_, ret,
> > -					     size, s->size, flags);
> > +			trace_kmemtrace_alloc(KMEMTRACE_TYPE_KMALLOC,
> > +					      _THIS_IP_, ret,
> > +					      size, s->size, flags, -1);
> >  
> 
> Pass s as parameter and do the s->size dereference within the probe.
> 
> The same applies to many other caller sites below.

Same as first comment, it would entail having specific kmemtrace
functions for specific allocator functions within specific allocators.


	Eduard


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

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-29  1:40 [PATCH 0/3] kmemtrace over tracepoints Eduard - Gabriel Munteanu
2008-12-29  1:40 ` [PATCH 1/3] RCU: Move some definitions to minimal headers Eduard - Gabriel Munteanu
2008-12-29  9:42   ` Pekka Enberg
2008-12-29 12:32     ` Ingo Molnar
2008-12-30  6:31     ` Paul E. McKenney
2008-12-29 14:56   ` Ingo Molnar
2008-12-29  1:40 ` [PATCH 2/3] tracepoints: Include only minimal RCU headers in linux/tracepoint.h Eduard - Gabriel Munteanu
2008-12-29  1:40 ` [PATCH 3/3] kmemtrace: Use tracepoints instead of markers Eduard - Gabriel Munteanu
2008-12-29  9:44   ` Pekka Enberg
2009-01-02 20:54     ` Mathieu Desnoyers
2009-01-02 23:03       ` Eduard - Gabriel Munteanu
2008-12-29 13:43   ` Pekka Enberg
2008-12-29 20:11     ` Eduard - Gabriel Munteanu
2009-01-02 20:53   ` Mathieu Desnoyers
2009-01-02 23:01     ` Eduard - Gabriel Munteanu [this message]
2009-01-02 23:42       ` Mathieu Desnoyers
2009-01-04  1:53         ` Eduard - Gabriel Munteanu
2009-01-04  4:10         ` Eduard - Gabriel Munteanu
2009-01-05 16:05           ` Mathieu Desnoyers
2009-01-05 17:57             ` Eduard - Gabriel Munteanu
2009-01-05 18:09               ` Mathieu Desnoyers
2008-12-29  9:41 ` [PATCH 0/3] kmemtrace over tracepoints Pekka Enberg

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=20090102230116.GB5235@localhost \
    --to=eduard.munteanu@linux360.ro \
    --cc=adobriyan@gmail.com \
    --cc=dipankar@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=mingo@elte.hu \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox