Jeremy Linton [off-list ref] writes:

Hi,

On 09/16/2016 08:33 AM, Punit Agrawal wrote:

quoted

Jeremy Linton [off-list ref] writes:

quoted

Its possible that an ACPI system has multiple CPU types in it
with differing PMU counters. Iterate the CPU's and make a determination
about how many of each type exist in the system. Then take and create
a PMU platform device for each type, and assign it the interrupts parsed
from the MADT. Creating a platform device is necessary because the PMUs
are not described as devices in the DSDT table.

This code is loosely based on earlier work by Mark Salter.

(trimming)

quoted

quoted

+
+	list_for_each_entry_safe(pmu, safe_temp, &pmus, list) {
+		if (unused_madt_entries)
+			pmu->cpu_count = num_possible_cpus();

So if there is any unbooted cpu ...

quoted

+
+		res = kcalloc(pmu->cpu_count,
+				  sizeof(struct resource), GFP_KERNEL);

... we allocate potentially large number (num_possible_cpus()) of
resources for each PMU.

This is needlessly wasteful. Under what conditions have you found
reg_midr to be 0?

Unused MADT entries, in place for potentially unbooted/hotplug
CPUs.

Is linux able to deal with booting secondaries that have unused MADT
entries?

In those cases you don't know for sure which PMU the CPU belongs
to until it comes online and the MIDR can be read. I'm open to
suggestions on how to deal with this, outside of pushing my luck and
further breaking the platform device encapsulation by trying to
reallocate the resource structure while its active. Besides its only
wasteful for ACPI+big.little, which at the moment only applies to a
development platform.

I don't have any ideas to solve this problem, but in the interest of
helping review, please move all the changes arising from hotplug/unused
MADT entries in this patch to the next one.

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html