From owner-freebsd-current Sat Feb 1 13: 7:55 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 2946D37B401 for ; Sat, 1 Feb 2003 13:07:54 -0800 (PST) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 588AD43E4A for ; Sat, 1 Feb 2003 13:07:53 -0800 (PST) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id h11L5lO13223; Sat, 1 Feb 2003 16:05:47 -0500 (EST) (envelope-from bmilekic@unixdaemons.com) Date: Sat, 1 Feb 2003 16:05:47 -0500 From: Bosko Milekic To: Terry Lambert Cc: Matthew Dillon , "Daniel C. Sobral" , Trish Lynch , freebsd-current@FreeBSD.ORG Subject: Re: Hyperthreading and machdep.cpu_idle_hlt Message-ID: <20030201160547.A13169@unixdaemons.com> 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> <3E3C327F.FD9E26F7@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E3C327F.FD9E26F7@mindspring.com>; from tlambert2@mindspring.com on Sat, Feb 01, 2003 at 12:47:59PM -0800 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 On Sat, Feb 01, 2003 at 12:47:59PM -0800, Terry Lambert wrote: > 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? Because, the comment explains, a halted CPU will not pick up a new thread off the run queue until the next timer tick. So if all your logical units are idled then you can afford to just loop checking whether something is runnable without interfering with the performance of other threads running on a different logical cpu sharing your execution unit (because the other logical units are idle anyway). That way, you don't have to necessarily wait for the next timer tick to check whether something is runnable, especially if it's made runnable before. The disadvantage is that you don't really economize on power consumption. The ideal situation would be to have as Matt (and the comment actually) says a cpu mask of idle cpus and generate an IPI to wake up CPUs sitting in HLT when something hits the runqueue, then you can just hlt all of them and rely on the IPI to wake you up, or the next timer tick, whichever comes first and you can really get the best of both worlds. > -- Terry -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message