Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 01 Feb 2003 12:47:59 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Bosko Milekic <bmilekic@unixdaemons.com>
Cc:        Matthew Dillon <dillon@apollo.backplane.com>, "Daniel C. Sobral" <dcs@tcoip.com.br>, Trish Lynch <trish@bsdunix.net>, freebsd-current@FreeBSD.ORG
Subject:   Re: Hyperthreading and machdep.cpu_idle_hlt
Message-ID:  <3E3C327F.FD9E26F7@mindspring.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>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E3C327F.FD9E26F7>