Date: Thu, 27 Apr 2000 09:40:03 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Luoqi Chen <luoqi@watermarkgroup.com> Cc: smp@csn.net, bright@wintelcom.net, djb@ifa.au.dk, freebsd-smp@FreeBSD.ORG Subject: Re: hlt instructions and temperature issues Message-ID: <200004271640.JAA05314@apollo.backplane.com> References: <200004271623.e3RGNXX02617@lor.watermarkgroup.com>
index | next in thread | previous in thread | raw e-mail
:> running CPU detects both a hlt'de CPU and more than 1 READY process in the que.
:>
:> --
:> Steve Passe | powered by
:> smp@csn.net | Symmetric MultiProcessor FreeBSD
:>
:The halted CPU may not receive the interrupt only if there's another CPU
:also have 0 TPR value, which means the second CPU either
: o is halted as well. It doesn't matter which CPU got first waken up.
: o has the kernel lock. The interrupt should be handled by the second CPU
: any way. So not too much is lost, if the first CPU doesn't wake up.
:
:I can see there's still benefit to have the first CPU waken up in the
:second case. Why don't we change the TPR for the kernel lock holder to 1?
:...
When you are doing SMP work, you have to assume that an infinite number
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 interrupt
to occur?
The answer I think is yes. You can wind up in a situation where both
cpu's go idle but one takes an interrupt (which, say, wakes up a
process) before having a chance to HLT, then HLT's and never wakes
up again even though there is a runnable process.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004271640.JAA05314>
