Re: [PATCH V2 16/25] perf/x86: Register hybrid PMUs

["Liang, Kan" <kan.liang@linux.intel.com>]

On 3/10/2021 11:50 AM, Dave Hansen wrote:
> On 3/10/21 8:37 AM, kan.liang@linux.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