Support for Cluster of SMP (or workstation) in DragonFly

[Matthew Dillon]

:Hi, all
:
:I am new in DragonFly and just found this very interesting thing. I read 
:some doc about it but still several questions on it. (but some may be too 
:out-of-scope or too naive, please do forgive)
:
:1. In the initial motivation, DFL seems targeting on SMP machie(memory are 
:hardware shared in most case from my understanding). So is there any 
:consideration how those ides(like LWKT, IPI, messaging) support cluster of 
:SMP (or workstations) where messaging passing are the most common 
:programming model,and co-scheduling of parallel applications and global 
:synchronization accross cluster are major issues in them.

    DragonFly is designed to operate efficiently on both UP and SMP 
    machines.  That is, the algorithms we are choosing should theoretically
    work equally well on either type of platform.  The ultimate goal is to
    implement a transparent clustering capability.  This does not yet exist.
    Likewise, many of the MP algorithms are in place but much of the code
    remains under the Big Giant Lock, and will continue to remain under 
    that lock until we mostly finish the major infrastructure work (e.g.
    like VFS, which I am working on now).  We have to finish what subsystem
    threading we intend to do before we start worrying about undoing the 
    Big Giant Lock.

:2. Any benchmarks, or performance evaluation about DFl with other Unix?

    We haven't progressed far enough for benchmarks to really be meaningful,
    but at the moment our performance is similar to FreeBSD-4.x on UP machines,
    and hopefully a little better then 4.x on SMP machines.  On SMP boxes
    we beat FreeBSD-5 and 6 on some things, they beat us on other things,
    though I don't expect it to stay that way.  On UP boxes we are far more
    efficient then FreeBSD-5/6.

    For filesystem operations we are still using UFS, so our performance will
    be roughly similar to FreeBSD-4, which is to say better then FreeBSD-5
    but not as good as Linux (at least not for directory operations).  I
    think our NFS performance is very good, even when compared with Linux.

:3. What would impact the application programmer by introducing these new 
:features?

    The (not yet written) clustering is intended to be as transparent as
    possible, so I'm hoping that the app programmer will simple be able
    to rfork()/clone() as per normal... what will matter will be how much
    cross-thread pollution there winds up actually being.  That will
    ultimately govern how easily a program can be distributed in a clustered
    environment.

:4. Any consideration in DFl to please and take advantage of the new 
:architecture advancements, like hyperthreading, multi-core (or 
:chip-multithreading) in P4/Xeon, UltraSPARC IV, Power 4, etc
 
    Multi-core just looks like another cpu.  Hyperthreading only
    introduces minor improvements for particular types of problems, which 
    is why Intel is getting the pollucks beat out of it by AMD.  Both
    vendors are heading towards multi-core.  Hyperthreading is difficult 
    to deal with, so we don't really try other then to implement some minor
    affinity.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>

:5. more may come ... :)
:
:Thanks very much in advance
:Noah Yan 
:
: