Date: Thu, 27 Apr 2000 12:23:33 -0400 (EDT) From: Luoqi Chen <luoqi@watermarkgroup.com> To: smp@csn.net Cc: bright@wintelcom.net, djb@ifa.au.dk, freebsd-smp@FreeBSD.ORG Subject: Re: hlt instructions and temperature issues Message-ID: <200004271623.e3RGNXX02617@lor.watermarkgroup.com>
next in thread | raw e-mail | index | archive | help
> The problem is that if a CPU is in the hlt'd state it will never re-enter > cpu_switch() to be able to be assigned a new process, at least until it > happens to catch an INT that wakes it up and leaves it in cpu_switch at a point > where there is another ready process. It isn't guaranteed that the first INT > will be sent to the halted CPU, especially in a >2 CPU machine. As I stated > before, code is needed that sends a wakeup IPI from cpu_switch() when the > 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? So that an idle processor would receive interrupts first, if it couldn't get the kernel lock, it would IPI the lock holder. No cpu time is wasted, the only downside is a little higher latency for the interrupt. But you will gain when it is one of the fast interrupts, the idle process will handle the interrupt itself, without bothering the lock holder which is supposedly busy with something else. -lq 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?200004271623.e3RGNXX02617>