From owner-freebsd-smp Tue May 2 11:31:23 2000 Delivered-To: freebsd-smp@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 1417E37B585 for ; Tue, 2 May 2000 11:31:16 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id LAA16510; Tue, 2 May 2000 11:29:15 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp04.primenet.com, id smtpdAAA9daaKF; Tue May 2 11:28:25 2000 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id LAA21651; Tue, 2 May 2000 11:28:31 -0700 (MST) From: Terry Lambert Message-Id: <200005021828.LAA21651@usr01.primenet.com> Subject: Re: hlt instructions and temperature issues To: smp@csn.net (Steve Passe) Date: Tue, 2 May 2000 18:28:31 +0000 (GMT) Cc: djb@ifa.au.dk, kpielorz@tdx.co.uk (Karl Pielorz), smp@FreeBSD.ORG In-Reply-To: <200004301511.JAA16392@Ilsa.StevesCafe.com> from "Steve Passe" at Apr 30, 2000 09:11:12 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > 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... IMO, there is still the stalling issue, unless IPI code is brought in. Someone should take Peter up on his "offer" to write the trivial IPI code, and test that, as well. Personally, I think restarting another CPU is worth the 6uS that Matt thinks it will take. We are talking latency here; we have worse latency as a result of context switching anyway, IMO. I personally don't believe that there will be 5% overhead to this, and attribute the observed behaviour to stalling with a CPU coming idle with nothing in the ready-to-run. Whether there is stuff in the ready-to-run is the gating factor, I believe, between your benchmarks results. Also note that there is some minor destruction of affinity, and that a small affinity patch would probably be a heck of a lot more relevent. You wouldn't need to IPI, except when leaving the scheduler with the choice to migrate processes to another CPU's scheduler queue. This would be a significant win, and take only a minor amount of code, at the same time making the need for the BGL to go away for most scheduler operations (you would only need to grab the BGL when a lck cmpexchg resulted in a conflict). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message