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: Wed, 07 Apr 2010 11:04:53 +0200	[thread overview]
Message-ID: <1270631093.5109.569.camel@twins> (raw)
In-Reply-To: <1270567653.20295.11.camel@laptop>

On Tue, 2010-04-06 at 17:27 +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?
> 
> So looks good, altough I think we want to do that online/hotplug thing.

Alternatively, you can simply but the hash table into the per-cpu
structure and not allocate it, its only a single page (half a page if
you use 32bit or actually use 8 bits.



  reply	other threads:[~2010-04-07  9:06 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 [this message]
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=1270631093.5109.569.camel@twins \
    --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.