Where is FreeBSD going?

[Matthew Dillon]

:>     See?  I didn't mention DragonFly even once!  Ooops, I didn't mention
:>     DFly twice.  oops!  Well, I didn't mention it more then twice anyway.
:
:Makes me wonder if some of the solutions proposed by DragonFly could be 
:ported to FreeBSD, but I doubt it will be done, since it's more or less 
:admitting that the current solution is wrong.
:
:Yes, I mentioned DragonFly (how dare he!). Feel free to flame, I've 
:become extremely efficient at adding people to /etc/postfix/access :-P
:
:Cheers,
:-- 
:	Miguel Mendez <flynn at energyhq.es.eu.org>

    I think the correct approach to thinking about these abstractions would
    be to look at the code design implifications rather then just looking
    at performance, and then decide whether FreeBSD would benefit from
    the type of API simplification that these algorithms make possible.

    The best example of this that I have, and probably the *easiest*
    subsystem to port to FreeBSD (John could probably do it in a day),
    which I think would even wind up being exremely useful in a number
    of existing subsystems in FreeBSD (such as the slab allocator),
    would be DFly's IPI messaging code.  I use the IPI messaging abstraction
    sort of like a 'remote procedure call' interface... a way to execute
    a procedure on some other cpu rather then the current cpu.

    This abstraction allows me to execute operations on data structures
    which are 'owned' by another cpu on the target cpu itself, which means
    that instead of getting a mutex, operating on the data structure, and
    releasing the mutex, I simply send an asynch (don't wait for it to
    complete on the source cpu) IPI message to the target cpu.  By running
    the particular function, such as a scheduling request, in the target
    cpu's context, you suddenly find yourself in a situation where *NONE*
    of the related scheduler functions, and there are over a dozen of them,
    need to mess with mutexes.  Not one.  All they need to do to protect
    their turf is enter a critical section for a short period of time.
    The algorithm simplification is significant... you don't have to worry
    about crossing a thread boundary, you can remain in the critical section
    through the actual switch code which removes a huge number of special
    cases from the switch code.  You don't have to worry about mutexes
    blocking, you don't have to worry about futzing the owner of any mutexes,
    you don't have to worry about the BGL, you don't have to worry about
    stale caches between cpus, the code works equally well in a UP environment
    as it does in an SMP environment... cache pollution is minimized...
    the list goes on an on.

    So looking at these abstractions just from a performance standpoint
    misses some of the biggest reasons for why you might want to use them.
    Algorithmic simplification and maintainability are very important.
    Performance is important but not relevant if the resulting optimization
    cannot be maintained.

    In anycase, I use IPIs to do all sorts of things.  Not all have worked
    out... my token passing code, which I tried to use as a replacement
    for lockmgr interlocks, is pretty aweful and I consider it a conceptual
    failure.  But our scheduler, slab allocator, and messaging code,
    and a number of other mechanisms, benefit from huge simplifications
    through their use of IPI messaging.  Imagine... the messaging code
    is able to implement its entire API, including queueing and dequeueing
    messages on ports, without using a single mutex and (for all intents
    and purposes) without lock-related blocking.  The code is utterly
    simple yet works between cpus, between mainline code and interrupts
    with preemption capabilities, and vise-versa.  There are virtually no
    special cases.  Same with the slab code, except when it needs to 
    allocate a new zone from kernel_map, and same with the scheduler.

					    -Matt
					    Matthew Dillon 
					    <dillon at backplane.com>