Date: Mon, 25 Oct 1999 23:55:06 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: twinkle.star@263.net Cc: freebsd-smp@FreeBSD.ORG Subject: Re: inquire(second time) Message-ID: <199910252355.QAA16485@usr06.primenet.com> In-Reply-To: <001101bf1d44$ad4316e0$c226a8c0@jut.edu.cn> from "=?gb2312?B?s8LA8g==?=" at Oct 23, 99 06:52:08 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Dear Sir: > I would like to know how does the IRQs be handled in a SMP > system. Will they be handled by all the processors equally or > by a single processor? If it is the former,who will handle > them finally and what kind of lock mechanism will they follow? > > I expect for your answer and thank you very much for your > kindness and attention. > > In addtion, thank you very much for your telling me the > excellent aphorism. [ ... ] > Dear Sir: > I would like to know how does the IRQs be handled in > a SMP system. Will they be handled by all the processors > equally or by a single processor? If it is the former,who > will handle them finally and what kind of lock mechanism > will they follow: > > I expect for your answer and thank you very much for your > kindness and attention. > Yours sincerely, > Bill Chen You should read the Multiprocessor specification, version 1.4; it is available in PDF form from: http://developer.intel.com/design/pro/datashts/242016.htm The short answer is that Interrupts are handled according to the specification in "virtual wire" mode. This means that Interrupts are handled symmetrically by any of the processors in your system. Currently, only one processor is allowed into the kernel at a time. This means that two interrupts will not be handled concurrently by different processors. Serialization of processor entry into the kernel is handled by a single global kernel lock. The same lock is used for all kernel entry (traps, faults, and interrupts). BSDI has implemented interrupt handling using kernel threads which are lazy-bound. There has been some talk of doing this for FreeBSD, as well, but it is generally discounts as a bad idea, since the technique is 11 years old, and better techniques have been documented in the literature, such as a soft interrupt queue so that the interrupt handling process does not run to completion, rather just to the point where the hardwre can be disengaged. Because the I/O bus can not have simultaneous access for inb/outb for several processors (i.e., there is only one I/O bus), the code needed to actually signal or poll the hardware will likely need to always be serialized, at the lowest level. The need to exclusively access the I/O bus is one of the main factors sited for the developing RAMBus technology coming from major vendors. The console hardware, especially the keyboard and mouse I/O are also driving USB support into SMP machines in order to get larger buffers (keyboard LED maniuplation is one of the worst things you could do on an SMP box, since it is all inb/outb work, with huge spin latencies to not overwhelm the controller). I expect that the 3 and 4 processor Alpha systems from Compaq that are currently at Walnut Creek CDROM for FreeBSD Alpha SMP work will address many of these issues, though I suspect that the I/O bus on those systems, unless they are VME, is still going to have multiplex problems that require serialization. If the intent of the interrupt processing question is to get the best performance you can get out of the hardware, you would do well to not worry so much about the interrupt processing symmetry; one of the main things that NT did on the quad Xeon systems in order to get good numbers relative to Linux was to bind each one of the four 10/100 ethernet cards to a particular processor for interrupt handling. Frankly, you would be better off doing this, and picking hardware that could be communicated with in mapped memory regions instead of using the I/O bus for anything beyond initialization. PS: Please do not send BASE64 encoded ASCII data to the list; thanks. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199910252355.QAA16485>