From owner-svn-src-head@FreeBSD.ORG Wed Apr 22 22:30:29 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0FBE1065673; Wed, 22 Apr 2009 22:30:29 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id 080108FC20; Wed, 22 Apr 2009 22:30:28 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by ey-out-2122.google.com with SMTP id 9so59751eyd.7 for ; Wed, 22 Apr 2009 15:30:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=Xb91rhtGCcJtVRDJjlLNrO/Ho7S+6t7+NTjDAtzFpGI=; b=YBBL+L1jS/HIeCnJODlQGK2ByOejmH5P/5IjJM39Obq/zY0o6y/PBVN1d7NqweqGad zra9yycpOgmxu4LCQiVt9zGclG9N9IZ09OQ8FXZikdHXIbpPWA951QAxWvK97gk1oyyN wHLjUdbBOtSDO5Mgelyi4GINCL4Ni8S7lP0xQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=old4MVCjyDY0rFGVhi8jzvRBiPFnvDvBAD4sN3Szws9Mu+jj/pu50/owzF8efV1L9p 2DHjRk8N/jH82w+SQ/3EmSlQrq/DoSW7VU8OOC5e78dg3Ua7hdWlZDSdTPhQNT8ttqhP +pEgBfFp/pmlkXM4V8gbBWjmk5MN2EQCNwUCM= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.210.42.20 with SMTP id p20mr6835629ebp.30.1240439427871; Wed, 22 Apr 2009 15:30:27 -0700 (PDT) In-Reply-To: <200904221759.04446.jhb@freebsd.org> References: <200904222140.n3MLebn3068260@svn.freebsd.org> <200904221759.04446.jhb@freebsd.org> From: Ivan Voras Date: Thu, 23 Apr 2009 00:30:12 +0200 X-Google-Sender-Auth: e294c6569860a676 Message-ID: <9bbcef730904221530u786464d3v2dc05b0bb2f1218a@mail.gmail.com> To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 22:30:30 -0000 2009/4/22 John Baldwin : > 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: >> =C2=A0 Adjust the way we number CPUs on x86 so that we attempt to "group= " all >> =C2=A0 logical CPUs in a package. =C2=A0We do this by numbering the non-= boot CPUs >> =C2=A0 by starting with the first CPU whose APIC ID is after the boot CP= U and >> =C2=A0 wrapping back around to APIC ID 0 if needed rather than always st= arting >> =C2=A0 at APIC ID 0. =C2=A0While here, adjust the cpu_mp_announce() rout= ine to list >> =C2=A0 CPUs based on the mapping established by assign_cpu_ids() rather = than >> =C2=A0 making assumptions about the algorithm assign_cpu_ids() uses. > > An example is probably in order for this to make sense. =C2=A0Suppose you= have a > system with two quad-core CPUs. =C2=A0Package 0 has CPUs numbered 0, 1, 2= , and 3. > Package 1 has CPUs numbered 4, 5, 6, and 7. =C2=A0With the old code, if p= ackage 0 > won the election to be the boot processor, then CPU 0 would be the BSP an= d > the logical IDs would match the APIC IDs. =C2=A0However, 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. =C2=A0Thus, 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. =C2=A0However, when CPU 4 was the boot CPU= , CPUs 0 > and 5-7 where one package, and CPUs 1-4 where the second package. =C2=A0T= he 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 fro= m > the other package (APIC IDs 0-3). =C2=A0What 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?