From owner-freebsd-current Sat Feb 1 12:50: 4 2003 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 B87B237B405 for ; Sat, 1 Feb 2003 12:50:02 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEC1E43F3F for ; Sat, 1 Feb 2003 12:49:56 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0019.cvx22-bradley.dialup.earthlink.net ([209.179.198.19] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18f4Zs-0000jb-00; Sat, 01 Feb 2003 12:49:31 -0800 Message-ID: <3E3C327F.FD9E26F7@mindspring.com> Date: Sat, 01 Feb 2003 12:47:59 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bosko Milekic Cc: Matthew Dillon , "Daniel C. Sobral" , Trish Lynch , freebsd-current@FreeBSD.ORG Subject: Re: Hyperthreading and machdep.cpu_idle_hlt References: <20030131125804.E1357-100000@femme> <200301311824.h0VIOtmF095380@apollo.backplane.com> <3E3AC33E.9060204@tcoip.com.br> <200301311908.h0VJ8cNZ007396@apollo.backplane.com> <20030131141700.A7526@unixdaemons.com> <200301311952.h0VJqrMB076135@apollo.backplane.com> <20030201100412.B11945@unixdaemons.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4e1318a7d36e38d8406cc877557f64f37350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bosko Milekic wrote: > On Fri, Jan 31, 2003 at 11:52:53AM -0800, Matthew Dillon wrote: > > Another solution would be to have a global mask of 'idle' cpus and send > > an IPI to them when a new KSE is scheduled on a non-idle cpu that would > > simply serve to wakeup the HLT. IPIs are nasty, but there are large > > (power consumption) advantages to standardizing on the HLT methodology. > > Or, as I explained in my previous post, only HLT the [virtual] CPU if > the other [virtual] CPU that is sharing the same execution & cache > units is not HLT'd itself. If the other one is HLT'd, then not do the > HLT. Actually, why is that? Why would you not want to HLT all the units that are not being used? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message