[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9e5f9292-9767-d17a-2223-37dff9e759c7@linux.intel.com>
Date: Wed, 28 Aug 2019 15:35:02 -0400
From: "Liang, Kan" <kan.liang@...ux.intel.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: acme@...nel.org, mingo@...hat.com, linux-kernel@...r.kernel.org,
tglx@...utronix.de, jolsa@...nel.org, eranian@...gle.com,
alexander.shishkin@...ux.intel.com, ak@...ux.intel.com
Subject: Re: [RESEND PATCH V3 3/8] perf/x86/intel: Support hardware TopDown
metrics
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 value if its delta was less than
>> 1/255 of SLOTS (Fixed counter 3).
The "delta" is actually for the internal counters. Sorry for the
confusion.
> it also musn't be too cold. But that leaves it unspecified what exactly
> is the right range.
>
> IOW, you want a Goldilocks number of SLOTS.
>
>> Also, for counting, the -max_period is the initial value of the SLOTS.
>> The huge initial value will definitely trigger the issue mentioned
>> above. Force initial value as 0 for topdown and slots event counting.
> But you just told us that 0 is wrong too (too cold).
We set -max_period (0x8000 0000 0001) as initial value of FIXCTR3 for
counting. But the internal counters probably starts counting from 0.
PERF_METRICS is fraction of internal counters / FIXCTR3.
So PERF_METRICS will never works.
We have to make FIXCTR3 count from 0 as well.
Thanks,
Kan
Powered by blists - more mailing lists