From owner-freebsd-smp@FreeBSD.ORG Thu Jun 12 08:09:35 2003 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1E2F37B401; Thu, 12 Jun 2003 08:09:35 -0700 (PDT) Received: from smtp-relay2.barrysworld.com (smtp-relay2.barrysworld.com [213.221.172.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id D194243F85; Thu, 12 Jun 2003 08:09:34 -0700 (PDT) (envelope-from killing@barrysworld.com) Received: from [213.221.181.50] (helo=barrysworld.com) by smtp-relay2.barrysworld.com with esmtp (Exim 4.12) id 19QTgu-0007On-00; Thu, 12 Jun 2003 16:08:40 +0100 Received: from steven [193.123.241.40] by barrysworld.com with ESMTP (SMTPD32-7.15) id A83817A8011C; Thu, 12 Jun 2003 16:11:52 +0100 Message-ID: <024201c330f4$e58fdcf0$7b07000a@int.mediasurface.com> From: "Killing" To: "Doug White" References: <012201c32fac$3f1cfa90$b3db87d4@vader> <20030612075426.F57541@carver.gumbysoft.com> Date: Thu, 12 Jun 2003 16:11:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 cc: freebsd-current@freebsd.org cc: freebsd-smp@freebsd.org Subject: Re: SMP in 5.1 cant deactivate hyperthreading X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2003 15:09:36 -0000 ----- Original Message ----- From: "Doug White" > > sysctl machdep.hlt_logical_cpus: > > machdep.hlt_logical_cpus: 1 > > Halting them will still cause the CPUs to be detected. They just won't do > any useful work. Yep but the issue is that all the core admin tools are unaware of this and hence include the virtual cores in idle calcs etc making load monitoring impossible without nasty cludges :( So what's the way forward? 1. Dont just use halt have a compile or other directive to disable them? 2. Update all tools to be halt aware? Personally I'd go with 2 all be it more work / ramifications on other 3rd party tools as it gives the benefit of also working when physical CPU's are halted. Which ever it needs someone to pick it up ASAP dont you think? Steve