Date: Fri, 28 Apr 2000 22:19:18 -0700 From: Peter Wemm <peter@netplex.com.au> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Luoqi Chen <luoqi@watermarkgroup.com>, bright@wintelcom.net, djb@ifa.au.dk, freebsd-smp@FreeBSD.ORG, smp@csn.net Subject: Re: hlt instructions and temperature issues Message-ID: <20000429051918.B52881CD7@overcee.netplex.com.au> In-Reply-To: Message from Matthew Dillon <dillon@apollo.backplane.com> of "Thu, 27 Apr 2000 10:01:44 PDT." <200004271701.KAA05490@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote:
> :> of instructions can run on cpu B between any two instructions running
> :> on cpu A. So think it through... if you have sti + BLAH + hlt and
> :> the 'nop' stalls for a long, long time, is it possible for an interrup
t
> :> to occur?
> :>
> :I don't quite get the question... Are you talking about we can't have BLAH
> :between sti and hlt? I think you are right. But we don't really need the
> :BLAH, as Steve has said, the idle cpu already has the lowest TPR.
> :-lq
>
> What happens when both cpu's go idle? As far as I can tell, when both
> cpu's go idle it is possible for an interrupt to occur on one or the
> other just at the point after the STI instruction when you are
> messing with the APIC, before the HLT instruction.
>
> Intel guarentees that an STI+HLT combination will not interrupt in the
> middle as long as the HLT instruction immediately follows the STI
> instruction. If you have a single instruction inserted inbetween them,
> that guarentee goes out the window.
I haven't read the full thread yet, but the reason why we turned HLT back
off last time was because of this scenario:
CPU1 - sees empty run queue, halts.
CPU2 - wakes up a new process making it runnable.
CPU1 - remains halted, we didn't generate an IPI on runqueue changes.
This was the situation last time we activated HALT. Things have changed
since then. For starters, there is an easy place to add an IPI send (C
code not asm), so it should be trivial to fix that particular part of the
problem now.
Other things have changed in -current's low level SMP code, I'm not sure if
it's a simple thing to reactivate it any more.
Cheers,
-Peter
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000429051918.B52881CD7>