Date: Fri, 7 Jul 2000 13:02:41 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Chuck Paterson <cp@bsdi.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: <200007072002.NAA01310@apollo.backplane.com> References: <200007071748.LAA14029@berserker.bsdi.com>
next in thread | previous 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.
For ipending it IS the same category. At least for i386. If you look at
the patchset you will see that the ipending code I wrote
is 100% MP safe.
:} 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.
You are assuming that you can program APIC at every state change that
would otherwise effect interrupt performance. That sounds rather
messy to me. With the ipending mechanism (which gives you the ability
to enter into an interrupt even with spin locks held), you only need
to decide what to do with the interrupt in *one* place in the code.
We had (and have) code strewn all over the FreeBSD to deal with the
APIC. It's a mess, and a mistake. A few strategic places, sure,
but everywhere? No.
For example, take the case where you want to tie a NIC interrupt to
a particular cpu. You could tie the interrupt and simply leave it
that way, and if the interrupt occurs at an inopportune time the
interrupt vector code can choose what to do:
* set ipending and return (the interrupt will be run the moment
the scheduler lock is released)
* forward the interrupt to another cpu
* do something else...
:} 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
-Matt
Matthew Dillon
<dillon@backplane.com>
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?200007072002.NAA01310>