On 8/31/2019 5:19 AM, Peter Zijlstra wrote:
Then there is no mucking about with that odd counter/metrics msr pair
reset nonsense. Becuase that really stinks.
You have to write them to reset the internal counters.
But not for ever read, only on METRIC_OVF.
The precision are lost if the coun
On Sat, Aug 31, 2019 at 02:13:05AM -0700, Stephane Eranian wrote:
> Andi,
>
> On Fri, Aug 30, 2019 at 5:31 PM Andi Kleen wrote:
> >
> > > the same manner. It would greatly simplify the kernel implementation.
> >
> > I tried that originally. It was actually more complicated.
> >
> > You can't real
On Sat, Aug 31, 2019 at 02:13:05AM -0700, Stephane Eranian wrote:
> With PERF_METRICS, the delta is always since previous read. If you read
> frequently enough you do not lose precision.
You always loose precision, the whole fraction of 255 looses the
fractional part; consider:
255 * 1 / 8
31.87
On Wed, Aug 28, 2019 at 12:04:45PM -0700, Andi Kleen wrote:
> > > NMI
> > > ==
> > >
> > > The METRICS register may be overflow. The bit 48 of STATUS register
> > > will be set. If so, update all active slots and metrics events.
> >
> > that happen? It would be useful to get that METRIC_OVF
On Thu, Aug 29, 2019 at 12:56:02PM -0400, Liang, Kan wrote:
> On 8/29/2019 9:52 AM, Peter Zijlstra wrote:
> > What what? The PERF_METRICS contents depends on the FIXCTR3 value ?!
>
> Yes.
>
> For current implementation, PERF_METRIC MSR is composed by four fields,
> backend bound, frontend bound,
Andi,
On Fri, Aug 30, 2019 at 5:31 PM Andi Kleen wrote:
>
> > the same manner. It would greatly simplify the kernel implementation.
>
> I tried that originally. It was actually more complicated.
>
> You can't really do deltas on raw metrics, and a lot of the perf
> infrastructure is built around
> the same manner. It would greatly simplify the kernel implementation.
I tried that originally. It was actually more complicated.
You can't really do deltas on raw metrics, and a lot of the perf
infrastructure is built around deltas.
To do the regular reset and not lose precision over time inte
Hi,
On Mon, Aug 26, 2019 at 7:48 AM wrote:
>
> From: Kan Liang
>
> Intro
> =
>
> Icelake has support for measuring the four top level TopDown metrics
> directly in hardware. This is implemented by an additional "metrics"
> register, and a new Fixed Counter 3 that measures pipeline "slots".
>
On 8/29/2019 9:52 AM, Peter Zijlstra wrote:
On Thu, Aug 29, 2019 at 09:31:37AM -0400, Liang, Kan wrote:
On 8/28/2019 11:19 AM, Peter Zijlstra wrote:
+static int icl_set_topdown_event_period(struct perf_event *event)
+{
+ struct hw_perf_event *hwc = &event->hw;
+ s64 left = local6
On Thu, Aug 29, 2019 at 09:31:37AM -0400, Liang, Kan wrote:
> On 8/28/2019 11:19 AM, Peter Zijlstra wrote:
> > > +static int icl_set_topdown_event_period(struct perf_event *event)
> > > +{
> > > + struct hw_perf_event *hwc = &event->hw;
> > > + s64 left = local64_read(&hwc->period_left);
> > > +
>
On 8/28/2019 11:19 AM, Peter Zijlstra wrote:
+static int icl_set_topdown_event_period(struct perf_event *event)
+{
+ struct hw_perf_event *hwc = &event->hw;
+ s64 left = local64_read(&hwc->period_left);
+
+ /*
+* Clear PERF_METRICS and Fixed counter 3 in initializatio
On Wed, Aug 28, 2019 at 08:11:51PM -0700, Andi Kleen wrote:
> On Wed, Aug 28, 2019 at 06:28:57PM +0200, Peter Zijlstra wrote:
> > On Wed, Aug 28, 2019 at 09:17:54AM -0700, Andi Kleen wrote:
> > > > This really doesn't make sense to me; if you set FIXED_CTR3 := 0, you'll
> > > > never trigger the ov
On Wed, Aug 28, 2019 at 06:28:57PM +0200, Peter Zijlstra wrote:
> On Wed, Aug 28, 2019 at 09:17:54AM -0700, Andi Kleen wrote:
> > > This really doesn't make sense to me; if you set FIXED_CTR3 := 0, you'll
> > > never trigger the overflow there; this then seems to suggest the actual
> >
> > The 48b
On 8/28/2019 11:02 AM, Peter Zijlstra wrote:
Reset
==
The PERF_METRICS and Fixed counter 3 have to be reset for each read,
because:
- The 8bit metrics ratio values lose precision when the measurement
period gets longer.
So it musn't be too hot,
- The PERF_METRICS may report wrong va
On Wed, Aug 28, 2019 at 05:02:38PM +0200, Peter Zijlstra wrote:
> >
> > To avoid reading the METRICS register multiple times, the metrics and
> > slots value can only be updated by the first slots/metrics event in a
> > group. All active slots and metrics events will be updated one time.
>
> Can'
On Wed, Aug 28, 2019 at 09:17:54AM -0700, Andi Kleen wrote:
> > This really doesn't make sense to me; if you set FIXED_CTR3 := 0, you'll
> > never trigger the overflow there; this then seems to suggest the actual
>
> The 48bit counter might overflow in a few hours.
Sure; the point is? Kan said it
> This really doesn't make sense to me; if you set FIXED_CTR3 := 0, you'll
> never trigger the overflow there; this then seems to suggest the actual
The 48bit counter might overflow in a few hours.
-Andi
On Mon, Aug 26, 2019 at 07:47:35AM -0700, kan.li...@linux.intel.com wrote:
> diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> index 54534ff00940..1ae23db5c2d7 100644
> --- a/arch/x86/events/core.c
> +++ b/arch/x86/events/core.c
> @@ -76,6 +76,8 @@ u64 x86_perf_event_update(struct perf
On Mon, Aug 26, 2019 at 07:47:35AM -0700, kan.li...@linux.intel.com wrote:
> Groups
> ==
>
> To avoid reading the METRICS register multiple times, the metrics and
> slots value can only be updated by the first slots/metrics event in a
> group. All active slots and metrics events will be updat
19 matches
Mail list logo
