Re: [PATCH v2] cpufreq: Register with perf domain before

[Lukasz Luba <lukasz.luba@arm.com>]

Hi Viresh, Vincent

I'm surprised seeing this thread and thanks that you Viresh have
answered, so it could go through my spam/junk filters.
(I hope when answer to that domain it would change something).

On 1/18/23 08:49, Viresh Kumar wrote:
> On 18-01-23, 12:47, Vincent Wang wrote:
>> From: Vincent Wang <vincentwang3@lenovo.com>
>>
>> We found the following issue during kernel boot on android phone:
>>
>> [    1.325272][    T1] cpu cpu0: EM: created perf domain
>> [    1.329317][    T1] cpu cpu4: EM: created perf domain
>> [    1.337597][   T76] pd_init: no EM found for CPU7
>> [    1.350849][    T1] cpu cpu7: EM: created perf domain
>>
>> pd init for cluster2 is executed in a kworker thread and
>> is earlier than the perf domain creation for cluster2.
> 
> Can you please give detail of the exact code path, for mainline kernel
> ? I am not sure which kworker thread are you talking about here.

Please also tell us your cpufreq governor. The schedutil governor
at mainline can handle those situations and we rebuild the perf domains
here [1].

> 
>> pd_init() is called from the cpufreq notification of
>> CPUFREQ_CREATE_POLICY in cpufreq_online(), which is earlier
>> than that cpufreq_driver->register_em() is called.

Viresh, If that's an issue for other governors, than maybe
we should address that. IMO the patch just relies on side-effect
in arch_topology.c update_topology_flags_workfn(). That would be
a workaround and dangerous if someone would change that arch_topology.c
design. Shouldn't we come up with something reliable inside the
cpufreq.c if there is a real issue?
Even now, these two mechanisms:
1. in the schedutil [1]
2. in the update_topology_flags_workfn()
are a bit leaky (in terms of design holes).

Regards,
Lukasz

[1] 
https://elixir.bootlin.com/linux/latest/source/kernel/sched/cpufreq_schedutil.c#L858