Messages in this thread | | | Subject | Re: [PATCH V2 16/25] perf/x86: Register hybrid PMUs | From | "Liang, Kan" <> | Date | Wed, 10 Mar 2021 12:38:35 -0500 |
| |
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
| |