From owner-freebsd-current@FreeBSD.ORG Fri Sep 23 16:41:52 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D132216A41F; Fri, 23 Sep 2005 16:41:52 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14BEC43D46; Fri, 23 Sep 2005 16:41:49 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j8NGlxaW054786; Fri, 23 Sep 2005 12:47:59 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Fri, 23 Sep 2005 12:41:28 -0400 User-Agent: KMail/1.6.2 References: <200509211550.27524.jkim@FreeBSD.org> <43325114.4090907@gneto.com> <43325364.8090208@freebsd.org> In-Reply-To: <43325364.8090208@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <200509231241.31227.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV devel-20050919/1098/Thu Sep 22 16:57:50 2005 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Colin Percival Subject: Intel multi-core (Was: Re: [PATCH] AMD multicore detection) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2005 16:41:52 -0000 On Thursday 22 September 2005 02:47 am, Colin Percival wrote: > Martin Nilsson wrote: > > Jung-uk Kim wrote: > >> New patch is here: > >> http://people.freebsd.org/~jkim/multicore.diff > >> > >> Please test and let me know. I don't have multicore CPU to test > >> it for myself. :-( > > > > The below is on a Pentium D 820 (Dualcore). I don't like that the > > two cores are reported as hyperthreading when the CPU does not > > support hyperthreading (only the 840 EE does). If we ship 6.0 > > with HT disabled I'm afraid that it will turn off one of the > > cores, right? > > It shouldn't. Dual-core processors claim to be hyperthreaded, but > when I wrote the patch which disabled hyperthreading I added extra > (and rather complicated) code to detect dual-core processors and > *not* disable them. > > If I got it wrong, please let me know. :-) I just looked at 'IA-32 Intel® Architecture Software Developer's Manual, Volume 3: System Programming Guide': ftp://download.intel.com/design/Pentium4/manuals/25366817.pdf 7.7 DETECTING HARDWARE MULTI-THREADING SUPPORT AND TOPOLOGY Use the CPUID instruction to detect the presence of hardware multi-threading support in a physical processor. The following can be interpreted: - Hardware Multi-Threading feature flag (CPUID.1:EDX[28] = 1) -- Indicates when set that the physical package is capable of supporting Hyper-Threading Technology and/or multiple cores. - Logical processors per Package (CPUID.1:EBX[23:16]) -- Indicates the maximum number of logical processors in a physical package. This represents the hardware capability as the processor has been manufactured. - Cores per Package (CPUID.4:EAX[31:26] + 1) -- The maximum number of cores in a physical package is indicated by one plus the decimal value represented in CPUID.4:EAX[31:26]. This seems to be equivalent of AMD's Physical Core Count (CPUID.80000008:ECX[7:0] in Intel notation). But the footnote says: 2. Software must check CPUID for its support of leaf 4 when implementing support for multi-core. If CPUID leaf 4 is not available at runtime, software should handle the situation as if there is only one core per package. and 'IA-32 Intel® Architecture Software Developer's Manual, Volume 2A: Instruction Set Reference, A-M': ftp://download.intel.com/design/Pentium4/manuals/25366617.pdf Table 3-12, 3-158: CPUID leaves > 3 < 80000000 are visible only when IA32_MISC_ENABLES.BOOT_NT4[bit 22] = 0 (default). Unfortunately, I think not many BIOSes do that by default. (BTW, is it possible to turn the bit off after boot?) The leaf 4 (which is what you are actually using here) is unavailable unless the bit is 0. Therefore, it seems there's not much point to have the hack you added because you can use EAX[31:26] instead of cache properties if it is available. Jung-uk Kim