All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Paul Mackerras <paulus@samba.org>,
	Stephane Eranian <eranian@google.com>
Subject: Re: [PATCH] perf: Don't schedule tracepoints when exclude_kernel is set
Date: Tue, 12 Apr 2011 17:48:53 +0200	[thread overview]
Message-ID: <20110412154850.GA2240@nowhere> (raw)
In-Reply-To: <1302356262.9086.1280.camel@twins>

On Sat, Apr 09, 2011 at 03:37:42PM +0200, Peter Zijlstra wrote:
> On Sat, 2011-04-09 at 15:27 +0200, Frederic Weisbecker wrote:
> > On Sat, Apr 09, 2011 at 03:14:44PM +0200, Peter Zijlstra wrote:
> > > On Fri, 2011-04-08 at 22:57 +0200, Frederic Weisbecker wrote:
> > > > Instead of checking attr.exclude_kernel anytime a tracepoint
> > > > event triggers, simply don't schedule the tracepoint it that
> > > > attribute is set. This makes one test less in the tracing
> > > > path.
> > > 
> > > Meh, I'd much rather someone spend some time on finishing the below,
> > > which is a much bigger improvement for trace-events.
> > 
> > I secretely added that to my pile already :)
> > That's indeed something we really want.
> > 
> > The above is just a little thing I noticed yesterday and I wanted
> > to fix. Nothing more.
> > 
> > About that tracepoint collection, I'm not sure I like the idr though.
> > That thing seems to be O(log(n)), I which we can rather approach O(1)
> > when possible, using a hlist perhaps.
> 
> We only do 2 idr lookups at most and don't get to muck about with hash
> table collisions etc. But if you can show that that is the bottleneck
> you can replace the task/cpu idrs with a hashtable.

We can probably start with the irds to begin with. The implementation
can be enhanced anytime.

> 
> You will still need an IDR to deal with the traceevents (trace_type_idr)
> in order to get the dense ID space, and the per-event idr isn't used in
> the fast path at all.

Yep, no problem with that.

      reply	other threads:[~2011-04-12 15:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-08 20:57 [PATCH] perf: Don't schedule tracepoints when exclude_kernel is set Frederic Weisbecker
2011-04-09 13:14 ` Peter Zijlstra
2011-04-09 13:17   ` Ingo Molnar
2011-04-09 13:27   ` Frederic Weisbecker
2011-04-09 13:37     ` Peter Zijlstra
2011-04-12 15:48       ` Frederic Weisbecker [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=20110412154850.GA2240@nowhere \
    --to=fweisbec@gmail.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@redhat.com \
    --cc=eranian@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    /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.