RE: [PATCH v9 00/24] x86/resctrl: monitored closid+rmid together, separate arch/fs locking

Luck, Tony posted 24 patches 1 year, 11 months ago
Only 0 patches received!
There is a newer version of this series
RE: [PATCH v9 00/24] x86/resctrl: monitored closid+rmid together, separate arch/fs locking
Posted by Luck, Tony 1 year, 11 months ago
> So even though it is confirmed via lockdep_assert_cpus_held() that
> resctrl_arch_update_domains() holds cpu_hotplug_lock, it does not seem possible
> to have a similar lockdep check in the function called by it (resctrl_arch_update_domains())
> via IPI. It thus does not look like that lockdep checking within
> get_domain_from_cpu() can be accurate and I cannot see what it can be replaced with
> to make it accurate. Any guidance will be appreciated. Perhaps we should just drop (but
> with detailed context comments remaining) the lockdep check in get_domain_from_cpu()? 

Reinette

Both the places where this has problems (reset_all_ctrls() and
resctrl_arch_update_domains()) have similar structure:


	 list_for_each_entry(d, &r->domains, list) {
		add some bits to a cpumask
	}

	on_each_cpu_mask(cpu_mask, rdt_ctrl_update, &msr_param, 1);


Maybe instead of collecting all CPUs that need to do something, and then each
of them backtrack and search for the domain from a resource (that is passed
in the msr_param argument). The code could be restructured to pass the domain
to the target function. Like this:


	list_for_each_entry(d, &r->domains, list) {
		msr_param.dom = d;
		smp_call_function_single(somecpu, rdt_ctrl_update, &msr_param, 1);
	}

I'll try coding this up to see if it works.

-Tony