All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Paul Mackerras <paulus@samba.org>
Subject: Re: [PATCH] perf: Store active software events in a hashlist
Date: Tue, 06 Apr 2010 17:27:33 +0200	[thread overview]
Message-ID: <1270567653.20295.11.camel@laptop> (raw)
In-Reply-To: <1270476502-6214-1-git-send-regression-fweisbec@gmail.com>

On Mon, 2010-04-05 at 16:08 +0200, Frederic Weisbecker wrote:
> Each time a software event triggers, we need to walk through
> the entire list of events from the current cpu and task contexts
> to retrieve a running perf event that matches.
> We also need to check a matching perf event is actually counting.
> 
> This walk is wasteful and makes the event fast path scaling
> down with a growing number of events running on the same
> contexts.
> 
> To solve this, we store the running perf events in a hashlist to
> get an immediate access to them against their type:event_id when
> they trigger. 

So we have a hash-table per-cpu, each event takes a ref on the hash
table, when the thing is empty we free it.

When the event->cpu == -1 (all cpus) we take a ref on all possible cpu's
hash-table (should be online I figure, but that requires adding a
hotplug handler).

Then on event enable/disable we actually add the event to the hash-table
belonging to the cpu the event/task gets scheduled on, since each event
can only ever be active on one cpu.

Right?

So looks good, altough I think we want to do that online/hotplug thing.


  reply	other threads:[~2010-04-06 15:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-05 14:08 [PATCH] perf: Store active software events in a hashlist Frederic Weisbecker
2010-04-06 15:27 ` Peter Zijlstra [this message]
2010-04-07  9:04   ` Peter Zijlstra
2010-04-07 11:58     ` Frederic Weisbecker
2010-04-07 12:09       ` Peter Zijlstra
2010-04-08 19:39         ` [PATCH v2] " Frederic Weisbecker
2010-04-08 20:04           ` Eric Dumazet
2010-04-08 20:11             ` Frederic Weisbecker
2010-04-07 11:56   ` [PATCH] " Frederic Weisbecker
2010-04-07 11:58     ` Peter Zijlstra
2010-04-07 12:06       ` Frederic Weisbecker
2010-04-07  9:02 ` Peter Zijlstra
2010-04-07 11:52   ` Frederic Weisbecker
2010-04-07 11:56     ` Peter Zijlstra
2010-04-07 12:09       ` Frederic Weisbecker

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=1270567653.20295.11.camel@laptop \
    --to=peterz@infradead.org \
    --cc=acme@redhat.com \
    --cc=fweisbec@gmail.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.