Date: Fri, 28 Apr 2000 19:37:00 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Terry Lambert <tlambert@primenet.com> Cc: tlambert@primenet.com (Terry Lambert), 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: <200004290237.TAA21020@apollo.backplane.com> References: <200004290120.SAA11745@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> 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.
:
:I think that going outside is the least of the heat dissipation
:workies; it strikes me that line drivers are not where the heat
:is coming from, and that running over the same cache line would
:be a very bad thing.
Heat dissipation is caused mainly by gates on the chip changing state.
You can reduce the amount of gates that change state in a good portion
of the chip with careful coding. We aren't just talking about external
accesses here, though they are a big part of it. We are talking about,
for example, isolating the idle loop within a single code cache line
and the data accesses within a single data cache line. By doing so
the cache memory addressing will not change and since the cache memory
is essentially static ram using combinational decoding, this will save
a considerable amount of power and thus a considerable amount of heat.
I'm not sure if there are any tricks we can play to reduce dissipation
in the pipeline. Sometimes running very long-running instructions, like
DIV (try -1/-1 for example) in the middle of the loop works.
:The other problem with this idea is that you rely on a shootdown
:notification for a data change in order to exit the loop, and
:that is, defacto, an IPI in all but name.
We would rely on a data-change. The point is that the data change
is generated by an outside source (such as an interrupt or one of the
cpu's that IS running). A data change is very different from an IPI.
The overhead is much, much lower.
:I think the numbers for a 2 CPU system with Loqui's patch were
:extremely exagerated by the CPU stalling-until-interrupt issue,
:and that the heat numbers will not be nearly so good, even on a
:totally "correct" solotuion because of this. I expect your
:approach would result in temeperatures nearly as high, if not
:downright indistinguishable from, the measured numbers for an
:unmodified system.
Possibly, but possibly not. I don't know the intel architecture well
enough to say for sure. I've done a lot of low-power design so I do
know that these sorts of tricks work - often quite well. But Intel
has never been particularly good at doing low-power cpu designs.
-Matt
:This is really not an issue, anyway, except for power consumption
:and heat dissipation critical environments, but that said, if it's
:for an SMP box going into a colocation server room rack somewhere
:in a 1U case, this could be significant for some percentage of
:users, so maybe it's worth still talking about. 8-).
:
: Terry Lambert
: terry@lambert.org
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?200004290237.TAA21020>