[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1309527416.12449.729.camel@twins>
Date: Fri, 01 Jul 2011 15:36:56 +0200
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Robert Richter <robert.richter@....com>
Cc: Francis Moreau <francis.moro@...il.com>,
"linux-tip-commits@...r.kernel.org"
<linux-tip-commits@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"hpa@...or.com" <hpa@...or.com>,
"mingo@...hat.com" <mingo@...hat.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...e.hu" <mingo@...e.hu>
Subject: Re: [tip:perf/core] perf: Ignore non-sampling overflows
On Thu, 2011-06-30 at 14:47 +0200, Robert Richter wrote:
>
> It covers the case there the sampling period may be specified in the
> raw config register (line 286). I know, this is not the preferred way,
> but this way you can directly set the config value in perf without
> bypassing some bits through event->attr. As IBS events are sampling
> events I will change the code so that it writes back the specified
> period to event->attr.sample_period/event->hw.sample_period. Something
> like:
>
> if (event->hw.sample_period) {
> ...
> } else {
> max_cnt = event->attr.config & map->cnt_mask;
> event->attr.sample_period = max_cnt << 4;
> event->hw.sample_period = event->attr.sample_period;
> }
>
> This will then proper identify IBS samples as samling event.
Ah, being a naught boy then ;-), yeah passing stuff through like that
will confuse bits and the fixup you propose will indeed work around
that.
But why complicate things like this? You just add extra code to the init
path since you need to support attr.sample_period input as well.
--
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