Skip site navigation (1)Skip section navigation (2)
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>