Date: Thu, 02 May 2002 09:56:20 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: John Baldwin <jhb@FreeBSD.org> Cc: Andrew Gallatin <gallatin@cs.duke.edu>, freebsd-smp@FreeBSD.org Subject: Re: hlt when idle? Message-ID: <3CD16FB4.17BC09B@mindspring.com> References: <XFMail.20020502100023.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > > This seems to be an acceptable "loss" in performance in environments > > where cooling is a concern. Is there a deadlock danger? Or is it > > just a performance tweak to not HLT SMPs? Would you object to making > > it a sysctl (machdep.smp_idle_hlt)? > > Another thing that would be possible would be to try to narrow the race > further by keeping track of idle cpu's and sending out IPI's when threads > are made runnable. I suggested this already, but recommended against it. So did Peter. Like I said before, this has the problem of spurious IPI delivery to already running processors (if done right; if done wrong, you can still miss IPIs). The problem is that you can't close a race window on knowing the HLT state and being in the HLT state, because there's not a cmpxchnghlt instruction. You can only cause an overlap, so you get spurious notification instead of no notification. > > So each CPU gets (1/num_cpu) * hz clock interrupts/sec? > > Well, I'm not sure how the interrupts are routed exactly, so I would > tentatively say "roughly" that many. We ipi everyone else when we get > a clock interrupt on x86 to do effective broadcast interrupts. The clock interrupt gets sent to the ISA PIC, and maybe also to the APIC. The ISA PIC routes its interrupt to a single APIC input. THis is why if you mask ISA interrupts at the APIC, you can *lose* them. If the clock comes into an APIC input directly, instead of coming in indirectly via the ISA PIC, then it's routing is controlled by the APIC ICR entry for the APIC input. You should really read the Intel MP Specification, v1.4 (it was long enough ago that I did that it was easy for me to screw up my use of their terminology and mix up "virtual wire mode" with "symmetric I/O mode" because of the definition of the words in the title of the mode vs. Intel's definition; I can imagin others would have a similar problem unless they read the spec.). -- Terry 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?3CD16FB4.17BC09B>