From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Robert Richter <robert.richter@amd.com>,
Stephane Eranian <eranian@google.com>,
Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
Lin Ming <ming.m.lin@intel.com>
Subject: Re: [PATCH 0/3] perf/core, x86: unify perfctr bitmasks
Date: Tue, 30 Mar 2010 23:18:13 +0400 [thread overview]
Message-ID: <20100330191813.GF5211@lenovo> (raw)
In-Reply-To: <1269975840.5258.609.camel@laptop>
On Tue, Mar 30, 2010 at 09:04:00PM +0200, Peter Zijlstra wrote:
> On Tue, 2010-03-30 at 22:29 +0400, Cyrill Gorcunov wrote:
> > On Tue, Mar 30, 2010 at 06:55:13PM +0200, Peter Zijlstra wrote:
> > [...]
> > > -static int p4_hw_config(struct perf_event_attr *attr, struct hw_perf_event *hwc)
> > > +static int p4_hw_config(struct perf_event *event)
> > > {
> > > int cpu = raw_smp_processor_id();
> > > u32 escr, cccr;
> > > @@ -444,11 +431,29 @@ static int p4_hw_config(struct perf_even
> > > */
> > >
> > > cccr = p4_default_cccr_conf(cpu);
> > > - escr = p4_default_escr_conf(cpu, attr->exclude_kernel, attr->exclude_user);
> > > - hwc->config = p4_config_pack_escr(escr) | p4_config_pack_cccr(cccr);
> > > + escr = p4_default_escr_conf(cpu, event->attr.exclude_kernel,
> > > + event->attr.exclude_user);
> > > + event->hw.config = p4_config_pack_escr(escr) |
> > > + p4_config_pack_cccr(cccr);
> > >
> > > if (p4_ht_active() && p4_ht_thread(cpu))
> > > - hwc->config = p4_set_ht_bit(hwc->config);
> > > + event->hw.config = p4_set_ht_bit(event->hw.config);
> > > +
> > > + if (event->attr.type != PERF_TYPE_RAW)
> > > + return 0;
> > > +
> > > + /*
> > > + * We don't control raw events so it's up to the caller
> > > + * to pass sane values (and we don't count the thread number
> > > + * on HT machine but allow HT-compatible specifics to be
> > > + * passed on)
> > > + *
> > > + * XXX: HT wide things should check perf_paranoid_cpu() &&
> > > + * CAP_SYS_ADMIN
> > > + */
> > > + event->hw.config |= event->attr.config &
> > > + (p4_config_pack_escr(P4_ESCR_MASK_HT) |
> > > + p4_config_pack_cccr(P4_CCCR_MASK_HT));
> > >
> > > return 0;
> > > }
> > [...]
> >
> > P4 events thread specific is a bit more messy in compare with
> > architectural events. There are thread specific (TS) and thread
> > independent (TI) events. The exact effect of mixing flags from
> > what we call "ANY" bit is described in two matrix in SDM.
> >
> > So to make code simplier I chose to just bind events to a
> > particular logical cpu, when event migrate to say a second cpu
> > the bits just flipped in accordance on which cpu the event is
> > going to run. Pretty simple. Even more -- if there was some
> > RAW event which have set "ANY" bit -- they all will be just stripped
> > and event get bound to a single cpu.
> >
> > I'll try to find out an easy way to satisfy this "ANY" bit request
> > though it would require some time (perhaps today later or rather
> > tomorrow).
>
> Right, so don't worry about actively supporting ANY on regular events,
> wider than logical cpu counting is a daft thing.
>
> What would be nice to detect is if the raw event provided would be a TI
> (ANY) event, in which case we should apply the extra paranoia.
>
Well, there is a side effect would be anyway, so I think it should be
fixed via the way like: if a caller wanna get ANY event and this caller
has enough rights for that -- go ahead you'll get what you want,
kernel is not going to do a dirty work for you :) so I would need only
fix two procedures -- event assignment (where permission will be checked
as well) and event migration where I will not do any additional work for
the caller.
At least if I not miss anything it should not be quite difficult and
invasive. Will check and send patch... later a bit. At moment we're
on a safe side anyway, ie the former patch is fine for me!
-- Cyrill
next prev parent reply other threads:[~2010-03-30 19:18 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-29 16:36 [PATCH 0/3] perf/core, x86: unify perfctr bitmasks Robert Richter
2010-03-29 16:36 ` [PATCH 1/3] perf/core, x86: undo some some *_counter* -> *_event* renames Robert Richter
2010-04-02 19:09 ` [tip:perf/core] perf, x86: Undo " tip-bot for Robert Richter
2010-03-29 16:36 ` [PATCH 2/3] perf/core, x86: removing p6_pmu_raw_event() Robert Richter
2010-03-29 16:36 ` [PATCH 3/3] perf/core, x86: implement ARCH_PERFMON_EVENTSEL bit masks Robert Richter
2010-03-29 16:48 ` Peter Zijlstra
2010-03-29 17:01 ` Robert Richter
2010-03-30 9:28 ` Robert Richter
2010-04-02 19:09 ` [tip:perf/core] perf, " tip-bot for Robert Richter
2010-03-30 10:11 ` [PATCH 0/3] perf/core, x86: unify perfctr bitmasks Stephane Eranian
2010-03-30 13:41 ` Robert Richter
2010-03-30 13:53 ` Stephane Eranian
2010-03-30 15:00 ` Peter Zijlstra
2010-03-30 15:11 ` Cyrill Gorcunov
2010-03-30 15:31 ` Stephane Eranian
2010-03-30 15:59 ` Robert Richter
2010-03-30 16:55 ` Peter Zijlstra
2010-03-30 17:11 ` Cyrill Gorcunov
2010-03-30 17:24 ` Robert Richter
2010-03-30 18:29 ` Cyrill Gorcunov
2010-03-30 19:04 ` Peter Zijlstra
2010-03-30 19:18 ` Cyrill Gorcunov [this message]
2010-03-31 16:15 ` Cyrill Gorcunov
2010-03-31 16:26 ` Cyrill Gorcunov
2010-03-31 17:05 ` Cyrill Gorcunov
2010-04-01 2:14 ` Lin Ming
2010-04-01 6:47 ` Lin Ming
2010-04-01 10:36 ` Peter Zijlstra
2010-04-02 19:09 ` [tip:perf/core] perf, x86: Fix up the ANY flag stuff tip-bot for 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=20100330191813.GF5211@lenovo \
--to=gorcunov@gmail.com \
--cc=eranian@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.m.lin@intel.com \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=robert.richter@amd.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.