[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1289398677.2479.10.camel@localhost>
Date: Wed, 10 Nov 2010 22:17:57 +0800
From: Lin Ming <ming.m.lin@...el.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Ingo Molnar <mingo@...e.hu>, Matt Fleming <matt@...sole-pimps.org>,
"Zhang, Rui" <rui.zhang@...el.com>,
Frederic Weisbecker <fweisbec@...il.com>,
lkml <linux-kernel@...r.kernel.org>,
Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: [RFC PATCH 1/2] perf: Enable group siblings on exec if
attr::enable_on_exec set
On Wed, 2010-11-10 at 20:19 +0800, Peter Zijlstra wrote:
> On Wed, 2010-11-10 at 14:15 +0800, Lin Ming wrote:
> > Currently, only group leader is enabled on exec.
>
> That's enough, right? If all sibling events are already enabled enabling
> the group leader makes the whole thing go.
No.
If the event group is disabled by default("perf stat" case) and will be
enabled at next exec, then actually only the group leader will be
enabled , because all siblings are explicitly disabled(->state ==
PERF_EVENT_STATE_OFF). So the siblings will never be enabled.
/*
* Put a event into inactive state and update time fields.
* Enabling the leader of a group effectively enables all
* the group members that aren't explicitly disabled, so we
* have to update their ->tstamp_enabled also.
* Note: this works for group members as well as group leaders
* since the non-leader members' sibling_lists will be empty.
*/
static void __perf_event_mark_enabled(struct perf_event *event,
struct perf_event_context *ctx)
{
struct perf_event *sub;
event->state = PERF_EVENT_STATE_INACTIVE;
event->tstamp_enabled = ctx->time - event->total_time_enabled;
list_for_each_entry(sub, &event->sibling_list, group_entry)
if (sub->state >= PERF_EVENT_STATE_INACTIVE)
sub->tstamp_enabled =
ctx->time - sub->total_time_enabled;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists