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: <e8dd446f-f57c-dfbd-d923-b313411b74a0@linux.intel.com>
Date:   Wed, 10 Mar 2021 12:38:35 -0500
From:   "Liang, Kan" <kan.liang@...ux.intel.com>
To:     Dave Hansen <dave.hansen@...el.com>, peterz@...radead.org,
        mingo@...nel.org, linux-kernel@...r.kernel.org
Cc:     acme@...nel.org, tglx@...utronix.de, bp@...en8.de,
        namhyung@...nel.org, jolsa@...hat.com, ak@...ux.intel.com,
        yao.jin@...ux.intel.com, alexander.shishkin@...ux.intel.com,
        adrian.hunter@...el.com
Subject: Re: [PATCH V2 16/25] perf/x86: Register hybrid PMUs



On 3/10/2021 11:50 AM, Dave Hansen wrote:
> On 3/10/21 8:37 AM, kan.liang@...ux.intel.com wrote:
>> -	err = perf_pmu_register(&pmu, "cpu", PERF_TYPE_RAW);
>> -	if (err)
>> -		goto out2;
>> +	if (!is_hybrid()) {
>> +		err = perf_pmu_register(&pmu, "cpu", PERF_TYPE_RAW);
>> +		if (err)
>> +			goto out2;
>> +	} else {
>> +		u8 cpu_type = get_hybrid_cpu_type(smp_processor_id());
>> +		struct x86_hybrid_pmu *hybrid_pmu;
>> +		int i;
> 
> Where's the preempt_disable()?
> 
>> +static void init_hybrid_pmu(int cpu)
>> +{
>> +	unsigned int fixed_mask, unused_eax, unused_ebx, unused_edx;
>> +	struct cpu_hw_events *cpuc = &per_cpu(cpu_hw_events, cpu);
>> +	u8 cpu_type = get_hybrid_cpu_type(cpu);
>> +	struct x86_hybrid_pmu *pmu = NULL;
>> +	struct perf_cpu_context *cpuctx;
>> +	int i;
> 
> Ditto.
> 
> Are we really sure the IPIs are worth the trouble?  Why don't we just
> cache the leaf when we bring the CPU up like just about every other
> thing we read from CPUID?

Simple answer: You are right. We don't need it. A simple 
get_this_hybrid_cpu_type() should be fine for perf.

Here is the complete story.
I need the CPU type of the dead CPU in the cpu_dead. In the previous 
patch set, we can read it from the cached CPU type in the struct 
cpuinfo_x86.

In the V2 patch, I tried to do a similar thing (but I have to read it at 
runtime). Since the CPU is offlined, I asked Ricardo to provide the 
function get_hybrid_cpu_type() which can read the CPU type of a specific 
CPU. But I'm wrong. We cannot retrieve the valid CPU type from an 
offlined CPU. So I dropped the method and used another method to 
retrieve the information, but I didn't let Ricardo update the function. 
My bad.

Now, we only need to read the CPU type of the current CPU. A 
get_this_hybrid_cpu_type() function is enough for me.

I think we can get rid of the IPIs trouble with the new 
get_this_hybrid_cpu_type() in the next version. We shouldn't need the 
preempt_disable() either.

Thanks for pointing that out.

Kan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ