[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1297958714.2413.1929.camel@twins>
Date: Thu, 17 Feb 2011 17:05:14 +0100
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Stephane Eranian <eranian@...gle.com>
Cc: mingo@...hat.com, hpa@...or.com, linux-kernel@...r.kernel.org,
tglx@...utronix.de, mingo@...e.hu,
linux-tip-commits@...r.kernel.org
Subject: Re: [tip:perf/core] perf: Add cgroup support
On Thu, 2011-02-17 at 17:01 +0100, Stephane Eranian wrote:
> >
> > That part ended up avoiding a perf_clock() call, we could write that as:
> >
> > perf_cgroup_set_timestamp(current, ctx->timestamp);
> >
> > since ctx->timestamp has just been set to perf_clock().
>
> Ok so this one is just an optimization and not a locking problem, right?
Right, it was needed because we wanted to check ctx->lock, but if we
ensure we never call into the cgroup bits when we don't have an active
event that shouldn't be needed.
> I just realized that perf_cgroup_set_timestamp() is systematically
> calling perf_cgroup_from_task(). perf_events is touching cgroup
> data without knowing if this is really needed. But according to your
> earlier message, the call from __perf_event_enable() should be fine
> because we're holding ctx->lock. So I think we should be fine here.
Right, so if we keep poking at cgroup data for which we're not sure to
have an event (which itself pins the cgroup) we need this extra check
and the above gets done automagically due to passing ctx around.
--
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