All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
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: Wed, 7 Apr 2010 13:56:27 +0200	[thread overview]
Message-ID: <20100407115624.GD5143@nowhere> (raw)
In-Reply-To: <1270567653.20295.11.camel@laptop>

On Tue, Apr 06, 2010 at 05:27:33PM +0200, Peter Zijlstra wrote:
> 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?


Exactly.



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


That would let us allocate on online cpus instead of possibles? Yeah right.


  parent reply	other threads:[~2010-04-07 11:56 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
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   ` Frederic Weisbecker [this message]
2010-04-07 11:58     ` [PATCH] " 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=20100407115624.GD5143@nowhere \
    --to=fweisbec@gmail.com \
    --cc=acme@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.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.