From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Stephane Eranian <eranian@google.com>
Cc: mingo@redhat.com, hpa@zytor.com, linux-kernel@vger.kernel.org,
tglx@linutronix.de, mingo@elte.hu,
linux-tip-commits@vger.kernel.org
Subject: Re: [tip:perf/core] perf: Add cgroup support
Date: Thu, 17 Feb 2011 17:05:14 +0100 [thread overview]
Message-ID: <1297958714.2413.1929.camel@twins> (raw)
In-Reply-To: <AANLkTim2uXu+XBWdA-ZJOYFUyMrY+ze84QbMzohcN3Fo@mail.gmail.com>
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.
next prev parent reply other threads:[~2011-02-17 16:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-14 9:20 [PATCH 1/2] perf_events: add cgroup support (v9) Stephane Eranian
2011-02-15 14:55 ` Peter Zijlstra
2011-02-15 15:01 ` stephane eranian
2011-02-16 13:46 ` [tip:perf/core] perf: Add cgroup support tip-bot for Stephane Eranian
2011-02-16 16:57 ` Peter Zijlstra
2011-02-17 11:16 ` Stephane Eranian
2011-02-17 11:36 ` Peter Zijlstra
2011-02-17 14:45 ` Stephane Eranian
2011-02-17 15:50 ` Peter Zijlstra
2011-02-17 16:01 ` Stephane Eranian
2011-02-17 16:05 ` Peter Zijlstra [this message]
2011-02-17 16:13 ` Ingo Molnar
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=1297958714.2413.1929.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=eranian@google.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
/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