Date: Thu, 27 Apr 2000 10:56:58 -0600 From: Steve Passe <smp@csn.net> To: Luoqi Chen <luoqi@watermarkgroup.com> Cc: bright@wintelcom.net, djb@ifa.au.dk, freebsd-smp@FreeBSD.ORG Subject: Re: hlt instructions and temperature issues Message-ID: <200004271656.KAA25062@Ilsa.StevesCafe.com> In-Reply-To: Your message of "Thu, 27 Apr 2000 12:23:33 EDT." <200004271623.e3RGNXX02617@lor.watermarkgroup.com>
next in thread | previous 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, Its been several years since I coded the APIC stuff, but I seem to remember that there is also a mechanism where CPUs adjust their level depending on other "factors" (which I would need to refer to the docs to remeber the specifics of). 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. There are several scenarios that I remember, including: CPU0 running at spl level <anything set> CPU1 hlt'd INT occurs, CPU1 is woken and starts to process the ISR. first level ISR routine is locked out by spl, marks INT pending, CPU1 hlts again. CPU0 gets to splx(), sees the pending INT, processes it, processing of INT causes another process to become ready. CPU0 continues running it current process, CPU1 still hlt'd, "newly readied" process remains on que. CPU0 hits end of its quantum, reschedules, runs "newly readied" process, CPU1 remains hlt'd. > > 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. apic_vector.s: We already do forward INTs: 0: ; \ APIC_ITRACE(apic_itrace_tryisrlock, irq_num, APIC_ITRACE_TRYISRLOCK) ;\ MP_TRYLOCK ; /* XXX this is going away... */ \ testl %eax, %eax ; /* did we get it? */ \ jz 3f ; /* no */ \ ... 3: ; /* other cpu has isr lock */ \ APIC_ITRACE(apic_itrace_noisrlock, irq_num, APIC_ITRACE_NOISRLOCK) ;\ lock ; \ orl $IRQ_BIT(irq_num), _ipending ; \ testl $IRQ_BIT(irq_num), _cpl ; \ jne 4f ; /* this INT masked */ \ call forward_irq ; /* forward irq to lock holder */ \ -- you might have a point about setting the BGL holder to apic prio 1 instead of 0, in the case of fast INTs this might be a win, but for regular INTs its cheaper for the BGL holder to get them directly from the hardware. Testing is the only clear way to tell. My guess is that for most situations the extra INT latency isn't worth the gain for fast INTs (sio and ???). -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004271656.KAA25062>