From owner-freebsd-smp Thu Apr 27 9:40: 8 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 2021337BAD2 for ; Thu, 27 Apr 2000 09:40:06 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA05314; Thu, 27 Apr 2000 09:40:03 -0700 (PDT) (envelope-from dillon) Date: Thu, 27 Apr 2000 09:40:03 -0700 (PDT) From: Matthew Dillon Message-Id: <200004271640.JAA05314@apollo.backplane.com> To: Luoqi Chen Cc: smp@csn.net, bright@wintelcom.net, djb@ifa.au.dk, freebsd-smp@FreeBSD.ORG Subject: Re: hlt instructions and temperature issues References: <200004271623.e3RGNXX02617@lor.watermarkgroup.com> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> running CPU detects both a hlt'de CPU and more than 1 READY process in the que. :> :> -- :> Steve Passe | powered by :> smp@csn.net | Symmetric MultiProcessor FreeBSD :> :The halted CPU may not receive the interrupt only if there's another CPU :also have 0 TPR value, which means the second CPU either : o is halted as well. It doesn't matter which CPU got first waken up. : o has the kernel lock. The interrupt should be handled by the second CPU : any way. So not too much is lost, if the first CPU doesn't wake up. : :I can see there's still benefit to have the first CPU waken up in the :second case. Why don't we change the TPR for the kernel lock holder to 1? :... When you are doing SMP work, you have to assume that an infinite number of instructions can run on cpu B between any two instructions running on cpu A. So think it through... if you have sti + BLAH + hlt and the 'nop' stalls for a long, long time, is it possible for an interrupt to occur? The answer I think is yes. You can wind up in a situation where both cpu's go idle but one takes an interrupt (which, say, wakes up a process) before having a chance to HLT, then HLT's and never wakes up again even though there is a runnable process. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message