Date: Fri, 28 Apr 2000 15:40:33 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Terry Lambert <tlambert@primenet.com> Cc: jgowdy@home.com (Jeremiah Gowdy), smp@csn.net (Steve Passe), jim@thehousleys.net (James Housley), freebsd-smp@FreeBSD.ORG Subject: Re: hlt instructions and temperature issues Message-ID: <200004282240.PAA14200@apollo.backplane.com> References: <200004282108.OAA01313@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:Others have complained about the "air gap" between the "sti" and
:the "hlt". I think that this is not really an issue, but it's
:very easy to rectify this, if it were. It's clearly not an issue
:if the TPR claims are correct, and the new code merely removes
:the "#ifdef SMP/#endif" directives.
This is definitely an issue. If both cpu's go idle the interrupt
that's supposed to wake one of them up (e.g. some event that causes
a process to be woken up) can get lost in the air-gap.
It's trivial to rectify, so we should just do it :-). Besides, you
can't mess with the APIC stuff with interrupts enabled anyway because,
again, an interrupt might occur that alters the state of the system
just before or just after you modify the APIC priority. The sequence
of events should be: (1) mess with apic (2) sti (3) hlt.
These windows are small, but as we have seen an ample number of times
even one-instruction windows can get hit when the code in
question is being run thousands of times a second.
I like the HLT + IPI idea, but none of the patches to date really cover
the bases and switching performance is not going to be as good as when you
don't have the HLT due to the overhead of sending the IPIs and having to
keep track of which cpu's are in a HLT'd state and which are not (so you
don't send IPI's to all cpu's gratuitously).
This is not a trivial problem because we cannot afford to have N cpu's
all trying to do locked bitset instructions on the same memory location
in order to go idle -- that alone will create big latencies.
We should consider testing other possible solutions, such as having a
really tight idle loop that stays in the same cacheline and thus does
not greatly exercise the cpu's circuitry, resulting in less heat without
having to HLT.
For example, if we can remove *ALL* memory writes from the best-case
idle loop it should make a huge difference in heat dissipation without
having to resort to HLT! Right now we make a number of subroutine
calls (such as to procrunnable()) which will result in external
bus cycles. If those can be inlined it should have a noticeable effect.
-Matt
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?200004282240.PAA14200>