On 1/20/20 3:28 PM, Quentin Perret wrote:
On Monday 20 Jan 2020 at 15:53:35 (+0100), Dietmar Eggemann wrote:
Would be really nice if this wouldn't be required. We should really aim for 1 framework == 1 set of interfaces.
What happens if someone calls em_get_pd() on a CPU EM?
E.g:
static struct perf_domain *pd_init(int cpu) {
struct em_perf_domain *obj = em_cpu_get(cpu);
struct device *dev = get_cpu_device(cpu);struct em_perf_domain *obj = em_pd_get(dev); struct perf_domain *pd;Two versions of one functionality will confuse API user from the beginning ...
Agreed, this looks a bit confusing. It should be trivial to make em_dev_get() (or whatever we end up calling it) work for CPUs too, though. And we could always have a em_cpu_get(int cpu) API that is a basically a wrapper around em_dev_get() for convenience.
The problem not only here is that we have a CPU index 'int cpu' and if we ask for device like:
struct device *dev = get_cpu_device(cpu);
It might be not the same device that was used during the registration, when we had i.e. 4 CPUs for the same policy:
int cpu_id = cpumask_first(policy->cpus); struct device *cpu_dev = get_cpu_device(cpu_id); em_register_perf_domain(cpu_dev, nr_opp, &em_cb);
That's why the em_cpu_get() is different than em_get_pd(), mainly by: if (cpumask_test_cpu(cpu, em_span_cpus(em_pd)))
It won't be simple wrapper, let me think how it could be handled differently than it is now.
Regards, Lukasz
Thanks, Quentin