Date: Fri, 07 Jul 2000 11:48:34 -0600 From: Chuck Paterson <cp@bsdi.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Doug Rabson <dfr@nlsystems.com>, Greg Lehey <grog@lemis.com>, David Greenman <dg@root.com>, freebsd-smp@freebsd.org Subject: Re: Spin Locks, blocking interrupts, and ipending Message-ID: <200007071748.LAA14029@berserker.bsdi.com>
next in thread | raw e-mail | index | archive | help
Finally get a subject line. } } Well, the first isn't a disadvantage, since I implemented it a few } weeks ago. It was trivial. I maintain the the implementation to work on single running processor is not in the same category of difficulty as that needed to work on multiple processors. } } The second one doesn't apply to cli/sti verses ipending. I don't } see any relationship. Interrupt delivery is not controlled by } cli/sti, it's controlled by the APIC. } However, if the APIC is programmed to deliver interrupts to the right place, or not deliver them as the case may be, then there is no need for the ipending stuff. There is no way just using ipending to get the "right" job done was the point. }: }:Some random data points. }: }: The assumption that the scheduler lock will be the only }: spin mutex is wrong. BSD/OS currently has about 5 which }: are pretty much architecture independent. Most/all of these }: are at one time or another acquired while the scheduler }: lock is held. } } A per-process spin-held counter would address this both for } the scheduler mutex and any other spin mutex. } The comment I originally made here wasn't aimed at anything Matt said, but rather the comments others had made to the effect that the scheduler mutex was likely to be the only spin mutex. } } The only thing we use IPIs for seriously are VM page operations, } to invalidate pte's on other cpu's, and for interrupt forwarding } (which never worked quite right anyway). The former occurs only while } Giant is held. Hopefully it will eventually be the case that Giant isn't held when IPI's are sent. BSD/OS already dispatches pcpu clock IPIs without holding any locks. It certainly is the case with BSD/OS that the goal is to make Giant go away totally as soon as possible. However, I don't think this fundamentally changes anything. Chuck 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?200007071748.LAA14029>