Date: Wed, 01 May 2002 23:24:26 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: John Baldwin <jhb@FreeBSD.org> Cc: freebsd-smp@freebsd.org, Andrew Gallatin <gallatin@cs.duke.edu> Subject: Re: hlt when idle? Message-ID: <3CD0DB9A.143FCEC7@mindspring.com> References: <XFMail.20020501161535.jhb@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
John Baldwin wrote: > On 01-May-2002 Terry Lambert wrote: > > Andrew Gallatin wrote: > >> Can somebody remind me why we do not hlt in the idle loop on MP x86s? > > > > Halting with "giant" and/or "the scheduler lock" held is bad. > > Considering the idle loop doesn't hold any locks this doesn't apply. See the previously referenced discussion. The lock would have to be held, and/or all interrupts would have to be directed to the idle processor. There would still be a wakeup problem for any wakeup that triggered two or more things runnable simultaneously, since only one processor would wake up. There are a couple ways around this, but I think they are too ugly. > >> Do both CPUs get clock interrupts on x86? > > > > The clock interrupts may or may not be routed via the APIC; > > routing of the clock interrupt is one of the most common > > bogosities that you have to handle on x86 SMP systems; there > > is a special printf for complaining about having to work > > around broken BIOS and/or motherboard circuitry. > > You don't know what you are talking about. All the interrupts come > through the APIC. The hack that we do is to abuse the fact that > the normal AT PIC routes through the APIC to piggy back the clock > interrupt onto that (via routing it to the AT PIC). However, the > interrupt still comes to the CPU from the I/O APIc. It was my understanding that the AT PIC had to be directed, and could not run virtual wire. If this isn't correct, then my bad. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the messagehelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CD0DB9A.143FCEC7>