Date: Sat, 17 Jul 2004 18:46:44 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Don Bowman <don@sandvine.com> Cc: current@freebsd.org Subject: RE: panic: APIC: Previous IPI is stuck Message-ID: <200407180146.i6I1kiQ9004838@apollo.backplane.com> References: <FE045D4D9F7AED4CBFF1B3B813C85337051D936E@mail.sandvine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:Although you meant this as a bit of a joke (and
:it is kind of funny...) what would be involved
:in this port?
:
:Have you done any benchmarks to see how well
:this performs?
:
:--don
I would expect it to perform about the same as the existing code. The
main reasons to use it are that it consolidates the half dozen IPI
mechanisms used by FreeBSD-5 into *one* mechanism, it completely
solves deadlock issue(s), and it makes a really simple abstraction/API
available for the machine independant C code to use, which would lead to
greater use of the mechanism and less use of IPI-avoidance hacks (the
idle loop halt code and thread scheduling / thread scheduler mutex
being prime examples).
Examples of APIs that the IPI messaging can replace: clock distribution
(hardclock and statclock), signal forwarding/ast, page invalidation
(3 kinds), lazy pmap, SMP rendezvous. Examples of APIs that could use
IPI messaging instead of mutexes without too much fuss: core thread
scheduler, slab allocator, portions of the memory subsystem (well, maybe
the core thread scheduler would require some fuss).
It requires some assembly work, obviously, but no more then is already
required to mess with existing IPI mechanisms. Some per-cpu structural
work, and bringing in the code module. The callbacks would operate
about the same as a FAST interrupt from the point of view of FreeBSD-5.
A critical section should protect against an IPI callback occuring on
the current cpu (as it does in DFly).
The mechanism would be extremely useful even without implementing any
of the other myrid suggestions I've made (1), which is why I recommend it.
(1) nobody seems to have taken any of those suggestions seriously, but
the last few years of constant instability and continuing, serious code
and algorithmic fragility pretty much has proved my point that a major
simpification of your MP model is necessary to put FreeBSD-5 back on
track. I figure that if I cannot get FreeBSD-5 to adopt the most obviously
useful bit, which is the IPI Messaging, that I might as well give up
trying.
-Matt
Matthew Dillon
<dillon@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200407180146.i6I1kiQ9004838>