summaryrefslogtreecommitdiff
path: root/src/arch/x86/memcpy.c
diff options
context:
space:
mode:
authorWerner Zeh <werner.zeh@siemens.com>2019-02-19 13:39:56 +0100
committerPatrick Georgi <pgeorgi@google.com>2019-02-26 11:14:49 +0000
commitdb561e6e3910b25d9314ba8b343c4387396c2f3f (patch)
treeed91ef92aacdaa9f09a2d806012f3fe004198370 /src/arch/x86/memcpy.c
parentbd660e23382a74b399fa25ca01b9a9cd9c7683e9 (diff)
acpi: Sort the reported APIC-IDs in the MADT table
coreboot performs MP-Init in a parallel way. That leads to the fact that the order, in which the CPUs are woken up, can vary from boot to boot. The creation of the MADT table just parses the devicetree and takes the CPUs reported there as it is for creating the single local APIC entries. Therefore, the OS will see different order of CPUs. There are CPUs out there (like Apollo Lake for example) which have shared caches on core-level and if the order is random this can end up in assigning cores to different tasks or even OSes (in a virtual environment) which uses the same cache. This in turn will produce performance penalties across these distributed tasks/OSes. Though there is a way to discover the core- and cache-topology it will in the end be necessary to take the APIC-ID into account. To simplify it, one can achieve the same output by sorting the APIC-IDs in an ascending order. This will lead to the fact that CPUs that share a given cache will be reported right next to each other in the MADT. Change-Id: Ida74f9f00a4e2a03107a2124014403de60462735 Signed-off-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-on: https://review.coreboot.org/c/31545 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Diffstat (limited to 'src/arch/x86/memcpy.c')
0 files changed, 0 insertions, 0 deletions