From owner-freebsd-current@FreeBSD.ORG Sun Jul 18 01:46:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E35216A4CE for ; Sun, 18 Jul 2004 01:46:48 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A15F43D48 for ; Sun, 18 Jul 2004 01:46:46 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i6I1kids004839; Sat, 17 Jul 2004 18:46:44 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i6I1kiQ9004838; Sat, 17 Jul 2004 18:46:44 -0700 (PDT) (envelope-from dillon) Date: Sat, 17 Jul 2004 18:46:44 -0700 (PDT) From: Matthew Dillon Message-Id: <200407180146.i6I1kiQ9004838@apollo.backplane.com> To: Don Bowman References: cc: current@freebsd.org Subject: RE: panic: APIC: Previous IPI is stuck X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2004 01:46:48 -0000 :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