linux-kernel - Re: [PATCH 4/9] perf/x86/intel: Support hardware TopDown metrics

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <287c2c84-25cf-fdce-a3c3-49a6ee93ae4c@linux.intel.com>
Date:   Tue, 28 May 2019 14:23:09 -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: [PATCH 4/9] perf/x86/intel: Support hardware TopDown metrics



On 5/28/2019 8:43 AM, Peter Zijlstra wrote:
> On Tue, May 21, 2019 at 02:40:50PM -0700, kan.liang@...ux.intel.com wrote:
>> The 8bit metrics ratio values lose precision when the measurement period
>> gets longer.
>>
>> To avoid this we always reset the metric value when reading, as we
>> already accumulate the count in the perf count value.
>>
>> For a long period read, low precision is acceptable.
>> For a short period read, the register will be reset often enough that it
>> is not a problem.
> 
>> The PERF_METRICS may report wrong value if its delta was less than 1/255
>> of SLOTS (Fixed counter 3).
>>
>> To avoid this, the PERF_METRICS and SLOTS registers have to be reset
>> simultaneously. The slots value has to be cached as well.
> 
> That doesn't sound like it is NMI-safe.
>  >
> 
>> RDPMC
>> =========
>> The TopDown can be collected per thread/process. To use TopDown
>> through RDPMC in applications on Icelake, the metrics and slots values
>> have to be saved/restored during context switching.
>>
>> Add specific set_period() to specially handle the slots and metrics
>> event. Because,
>>   - The initial value must be 0.
>>   - Only need to restore the value in context switch. For other cases,
>>     the counters have been cleared after read.
> 
> So the above claims to explain RDPMC, but doesn't mention that magic
> value below at all. In fact, I don't see how the above relates to RDPMC
> at all.

Current perf only support per-core Topdown RDPMC. On Icelake, it can be 
extended to per-thread Topdown RDPMC.
It tries to explain the extra work for per-thread topdown RDPMC, e.g. 
save/restore slots and metrics value in context switch.


> 
>> @@ -2141,7 +2157,9 @@ static int x86_pmu_event_idx(struct perf_event *event)
>>   	if (!(event->hw.flags & PERF_X86_EVENT_RDPMC_ALLOWED))
>>   		return 0;
>>   
>> -	if (x86_pmu.num_counters_fixed && idx >= INTEL_PMC_IDX_FIXED) {
>> +	if (is_metric_idx(idx))
>> +		idx = 1 << 29;
> 
> I can't find this in the SDM RDPMC description. What does it return?

It will return the value of PERF_METRICS. I will add it in the changelog.

Thanks,
Kan
> 
>> +	else if (x86_pmu.num_counters_fixed && idx >= INTEL_PMC_IDX_FIXED) {
>>   		idx -= INTEL_PMC_IDX_FIXED;
>>   		idx |= 1 << 30;
>>   	}