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-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|