From owner-freebsd-smp Fri Apr 28 19:37: 5 2000 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 0E73837B723 for ; Fri, 28 Apr 2000 19:37:02 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA21020; Fri, 28 Apr 2000 19:37:00 -0700 (PDT) (envelope-from dillon) Date: Fri, 28 Apr 2000 19:37:00 -0700 (PDT) From: Matthew Dillon Message-Id: <200004290237.TAA21020@apollo.backplane.com> To: Terry Lambert 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 References: <200004290120.SAA11745@usr08.primenet.com> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> 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