From owner-freebsd-smp Sun Apr 30 8:11:23 2000 Delivered-To: freebsd-smp@freebsd.org Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [206.168.13.65]) by hub.freebsd.org (Postfix) with ESMTP id 1C48437B7F3 for ; Sun, 30 Apr 2000 08:11:20 -0700 (PDT) (envelope-from fbsd@Ilsa.StevesCafe.com) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.9.3/8.9.3) with ESMTP id JAA16392; Sun, 30 Apr 2000 09:11:12 -0600 (MDT) (envelope-from fbsd@Ilsa.StevesCafe.com) Message-Id: <200004301511.JAA16392@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0.2 2/24/98 From: Steve Passe To: djb@ifa.au.dk Cc: Karl Pielorz , smp@FreeBSD.ORG Subject: Re: hlt instructions and temperature issues In-reply-to: Your message of "Sun, 30 Apr 2000 16:38:24 +0200." <20000430163824.A1093@relativity.student.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 30 Apr 2000 09:11:12 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, > > > I personally wouldn't worry about 5% performance difference, and go for the > > > lower temperature and increased stability. But others may have different > > > opinions. My proposal is therefore to make the hlt instruction a kernel > > > option for SMP systems. That way everyone can experiment for themselves Some with experience in this area should make a sysctl that changes the value of _hlt_vector, one that has the hlt, another that doesn't: .globl _hlt_vector #ifdef SMP _hlt_vector: .long _no_halt /* pointer to halt routine */ #else _hlt_vector: .long _real_halt /* pointer to halt routine */ #endif ENTRY(no_halt) sti ret ENTRY(real_halt) sti hlt ret ... call *_hlt_vector /* wait for interrupt */ --- > > I don't like the 5% speed decrease either - our SMP systems are SMP because we > > need the speed. They are built to handle the thermals - so the thought of > > dropping 5% in speed isn't appealing... > > A matter of choice. And there isn't just a speed decrease, there can be an > increase also, as it was shown by Steve. As I said before, its "weird". I'm not ready to believe there is any speed increase yet... I expected a decrease, I was just trying to determine how much... Look at: http://people.FreeBSD.org/~fsmp/SMP/rbenches.html These are some baseline figures I took last week (indeed, the non-hlt, 4way numbers on the hlt graph are actually stolen from there). Notice that the 3way/j16 is actually faster than any 4way build. I attribute this to the BGL, ie, past 3 CPUs we actually loose ground competing for the lock and other such housekeeping. I'm thinking that the hlt instruction might be wasting CPU cycles by keeping CPUs hlt'd when there is useful work to do, but that this helps as there "isn't enough room in the kernel" for 4 CPUs anyway. I will run similar tests with a 3way kernel monday. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message