From: Peter Zijlstra <peterz@infradead.org>
To: kan.liang@intel.com
Cc: linux-kernel@vger.kernel.org, ak@linux.intel.com,
eranian@google.com, vincent.weaver@maine.edu, tglx@linutronix.de,
mingo@kernel.org, acme@redhat.com, jolsa@redhat.com,
ying.huang@linux.intel.com, alexander.shishkin@linux.intel.com
Subject: Re: [PATCH 1/1] perf/core: find auxiliary events in running pmus list
Date: Fri, 26 Feb 2016 11:36:58 +0100 [thread overview]
Message-ID: <20160226103658.GL6344@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <1456348836-6163-1-git-send-email-kan.liang@intel.com>
> index 9> +static void account_running_pmu(struct perf_event *event)
> +{
> + struct running_pmu *pmu;
> +
> + mutex_lock(&running_pmus_lock);
> +
> + list_for_each_entry(pmu, &running_pmus, entry) {
> + if (pmu->pmu == event->pmu) {
> + pmu->nr_event++;
> + goto out;
> + }
> + }
> +
> + pmu = kzalloc(sizeof(struct running_pmu), GFP_KERNEL);
> + if (pmu != NULL) {
> + pmu->nr_event++;
> + pmu->pmu = event->pmu;
> + list_add_rcu(&pmu->entry, &running_pmus);
> + }
That kzalloc() doesn't make any sense, why not simply add a member to
struct pmu?
> +out:
> + mutex_unlock(&running_pmus_lock);
> +}
In any case, can't we replace the whole perf_event_aux muck with a
data structure for finding interested events?
Because not only is iterating all PMUs silly, we then further iterate
all events in whatever contexts we find from them. Even if none of the
events in these contexts is interested in the side-band event.
We have:
mmap,comm,task,mmap_data,mmap2,comm_exec,context_switch
Which I think we can reduce like:
{mmap,mmap_data,mmap2} -> mmap
{comm,comm_exec} -> comm
mmap,comm,task,context_switch
This would allow us to keep 4 per-cpu lists of events like:
struct pmu_event_list {
raw_spinlock_t lock;
struct list_head list;
};
enum event_sb_channel {
sb_mmap = 0,
sb_comm,
sb_task,
sb_switch,
sb_nr,
}
static DEFINE_PER_CPU(struct pmu_event_list, pmu_sb_events[sb_nr]);
static void attach_sb_event(struct perf_event *event, enum event_sb_channel sb)
{
struct pmu_event_list *pel = per_cpu_ptr(&pmu_sb_events[sb], event->cpu);
raw_spin_lock(&pel->lock);
list_add_rcu(&event->sb_list[sb], &pel->list);
raw_spin_unlock(&pel->lock);
}
static void account_pmu_sb_event(struct perf_event *event)
{
if (event->parent)
return;
if (event->attach & ATTACH_TASK)
return;
if (event->attr.mmap || event->attr.mmap_data || event->attr.mmap2)
attach_sb_event(event, sb_mmap);
if (event->attr.comm || event->attr.comm_exec)
attach_sb_event(event, sb_comm);
if (event->attr.task)
attach_sb_event(event, sb_task);
if (event->attr.context_switch)
attach_sb_event(event, sb_switch);
}
/* matching unaccount */
static void perf_event_sb_iterate(enum event_sb_channel sb,
perf_event_sb_output_f output, void *data)
{
struct pmu_event_list *pel = __this_cpu_ptr(&pmu_sb_events[sb]);
struct perf_event *event;
list_for_each_entry_rcu(event, &pel->list, sb_list[sb]) {
if (event->state < PERF_EVENT_STATE_INACTIVE)
continue;
if (!event_filter_match(event))
continue;
output(event, data);
}
}
static void perf_event_sb_mask(unsigned int sb_mask, perf_event_sb_output_f output, void *data)
{
int sb;
for (sb = 0; sb < sb_nr; sb++) {
if (!(sb_mask & (1 << sb)))
continue;
perf_event_sb_iterate(sb, output, data);
}
}
Note: the mask is needed because a task event (as per perf_event_task)
needs to go out to sb_comm, sb_mmap and sb_task, see
perf_event_task_match().
And then you can replace the whole global part of perf_event_aux (which
I would rename to perf_event_sb), with this.
You still have to do something like:
for_each_task_context_nr(ctxn) {
ctx = rcu_dereference(current->perf_event_ctxp[ctxn]);
if (!ctx)
continue;
perf_event_sb_ctx(ctx, output, data);
}
To get at the per task events, because I don't think we want to go
update more global state on context switch, nor am I entirely sure its
worth it to keep per sb ctx->event_list[]s.
next prev parent reply other threads:[~2016-02-26 10:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-24 21:20 [PATCH 1/1] perf/core: find auxiliary events in running pmus list kan.liang
2016-02-25 8:17 ` Peter Zijlstra
2016-02-25 13:29 ` Alexander Shishkin
2016-02-25 15:38 ` Liang, Kan
2016-02-26 10:36 ` Peter Zijlstra [this message]
2016-02-28 16:31 ` Liang, Kan
2016-02-29 12:23 ` Peter Zijlstra
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=20160226103658.GL6344@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=acme@redhat.com \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=eranian@google.com \
--cc=jolsa@redhat.com \
--cc=kan.liang@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
--cc=vincent.weaver@maine.edu \
--cc=ying.huang@linux.intel.com \
/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