linux-kernel - Re: [PATCH V2 04/23] perf/x86/intel: Support adaptive PEBSv4

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]

Date:   Thu, 21 Mar 2019 20:40:03 -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 V2 04/23] perf/x86/intel: Support adaptive PEBSv4



On 3/21/2019 5:20 PM, Peter Zijlstra wrote:
> On Thu, Mar 21, 2019 at 01:56:44PM -0700, kan.liang@...ux.intel.com wrote:
>> @@ -933,6 +1001,34 @@ pebs_update_state(bool needed_cb, struct cpu_hw_events *cpuc, struct pmu *pmu)
>>   		update = true;
>>   	}
>>   
>> +	/*
>> +	 * The PEBS record doesn't shrink on the del. Because to get
>> +	 * an accurate config needs to go through all the existing pebs events.
>> +	 * It's not necessary.
>> +	 * There is no harmful for a bigger PEBS record, except little
>> +	 * performance impacts.
>> +	 * Also, for most cases, the same pebs config is applied for all
>> +	 * pebs events.
>> +	 */
>> +	if (x86_pmu.intel_cap.pebs_baseline && add) {
>> +		u64 pebs_data_cfg;
>> +
>> +		/* Clear pebs_data_cfg and pebs_record_size for first PEBS. */
>> +		if (cpuc->n_pebs == 1) {
>> +			cpuc->pebs_data_cfg = 0;
>> +			cpuc->pebs_record_size = sizeof(struct pebs_basic);
>> +		}
> 
> Argh, no. This is daft. The previous site was fine, it was just the
> pebs_record_size assignment I'm confused about.
> 
> Note how by setting ->pebs_data_cfs to 0, you force the below branch to
> true and call adaptive_pebs_record_size_update() ? So _why_ do you have
> to set pebs_record_size()?
>

I think we have to reset both cpuc->pebs_data_cfg and 
cpuc->pebs_record_size. Because pebs_update_adaptive_cfg() can return 0.
If so, adaptive_pebs_record_size_update() will not be called. The 
cpuc->pebs_record_size still use the stale data, which may be wrong.

I think there is no difference to reset them in first add or last del.
If so, I will keep the code here unchanged.

I will prepare V3 to address other comments.

Thanks,
Kan

>> +
>> +		pebs_data_cfg = pebs_update_adaptive_cfg(event);
>> +
>> +		/* Update pebs_record_size if new event requires more data. */
>> +		if (pebs_data_cfg & ~cpuc->pebs_data_cfg) {
>> +			cpuc->pebs_data_cfg |= pebs_data_cfg;
>> +			adaptive_pebs_record_size_update();
>> +			update = true;
>> +		}
>> +	}
>> +
>>   	if (update)
>>   		pebs_update_threshold(cpuc);
>>   }