Date: Thu, 23 Apr 2009 00:30:12 +0200 From: Ivan Voras <ivoras@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r191405 - in head/sys: amd64/amd64 i386/i386 Message-ID: <9bbcef730904221530u786464d3v2dc05b0bb2f1218a@mail.gmail.com> In-Reply-To: <200904221759.04446.jhb@freebsd.org> References: <200904222140.n3MLebn3068260@svn.freebsd.org> <200904221759.04446.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2009/4/22 John Baldwin <jhb@freebsd.org>: > On Wednesday 22 April 2009 5:40:37 pm John Baldwin wrote: >> Author: jhb >> Date: Wed Apr 22 21:40:37 2009 >> New Revision: 191405 >> URL: http://svn.freebsd.org/changeset/base/191405 >> >> Log: >> Adjust the way we number CPUs on x86 so that we attempt to "group" all >> logical CPUs in a package. We do this by numbering the non-boot CPUs >> by starting with the first CPU whose APIC ID is after the boot CPU and >> wrapping back around to APIC ID 0 if needed rather than always starting >> at APIC ID 0. While here, adjust the cpu_mp_announce() routine to list >> CPUs based on the mapping established by assign_cpu_ids() rather than >> making assumptions about the algorithm assign_cpu_ids() uses. > > An example is probably in order for this to make sense. Suppose you have a > system with two quad-core CPUs. Package 0 has CPUs numbered 0, 1, 2, and 3. > Package 1 has CPUs numbered 4, 5, 6, and 7. With the old code, if package 0 > won the election to be the boot processor, then CPU 0 would be the BSP and > the logical IDs would match the APIC IDs. However, if package 1 won the > election during POST, then CPU 0 would be APIC ID 4 on package 0 followed by > CPU 1 being APIC ID 0, CPU 2 being APIC ID 1, etc. Thus, when CPU 0 was the > boot CPU you had a nice grouping where CPUs 0-3 were a single package and > CPUs 4-7 were another package. However, when CPU 4 was the boot CPU, CPUs 0 > and 5-7 where one package, and CPUs 1-4 where the second package. The effect > of this patch is to change the case when CPU 4 is the boot CPU such that CPUs > 0-3 are now all from CPU 4's package (APIC IDs 4-7), and CPUs 4-7 are from > the other package (APIC IDs 0-3). What this means, in turn, is that in both > cases you now always have CPUs 0-3 as one package and CPUs 4-7 as another > package regardless of which CPU wins the boot-time election. I like that the new numbering is more elegant, but this is orthogonal to ULE topology detection, right?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9bbcef730904221530u786464d3v2dc05b0bb2f1218a>