Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
BSD Operating Systems

FreeBSD SMP Plans 27

Posted by Nik from the Also-from-Usenix dept.
Anonymous Coward writes: "A very interesting (if somewhat technical) synopsis of the Next Big Thing in FreeBSD SMP coming down the pipes from the geniuses on the FreeBSD core team. Some of the ideas are the beginnings of SMP discussions between BSDI and FreeBSD, along with some input from Yahoo. Very interesting reading!"
This discussion has been archived. No new comments can be posted.

FreeBSD SMP plans More

FreeBSD SMP plans

Comments Filter:
  • It _is_ an ADSL address, and the owner probably got upset with his bandwidth being eaten by being slashdotted.

    I better stay clear from him for a few months... :-)
  • It looks like Yahoo is pushing around it's snuff for a good cause.... Mmm.. SMP.. And the cool thing about *BSD, is when 1 BSD gets a reall really cool feature, chances all of them incorprate a bit of it.
  • I wonder what other features that Yahoo could push on. I doubt that they will fight for a Quake3 port.
  • Posted by 11223:

    You think they want their techies playing Quake 3 on their server? No way! :-P

  • Why here (Score:3)

    by sirket ( 60694 ) on Thursday June 22, 2000 @12:01PM (#984528)
    Why is something as important as a complete redesign of the FreeBSD SMP code sitting in the BSD only section and not on the main slashdot page?

    Just curious

    -sirket
  • The comment I'm replying to is not a troll, though it is factually incorrect.

    It's perfectly ok for someone to say one could use _another_ OS if one wants that feature.

    Of course, Linux doesn't have decent SMP for years now, and, as a matter of fact, they still don't have SMP at the level FreeBSD is now pushing for.

    What Linux _does_ have is, at the present, and for the past year or so (in the development branch), a much better SMP implementation than FreeBSD's present SMP implementation.

    I'm afraid the BSD/OS-inspired SMP will be raising the stakes, though. Mind you, for the first time since 2.0, FreeBSD's current branch will experience a continuous period of high instability for months. That's quite a price to pay...

  • Or you could just use Linux, which has already had the "really cool feature" for years now....

    FreeBSD has had SMP for quite a while as well. The point is that there are going to be major improvements to FreeBSD's SMP implementation, improvements which the other BSD's (and anyone else in the entire world, including Linux) would be free to incorporate in their own code.

  • Re:Moderate that back... (Score:1)

    by Anonymous Coward
    > What are the chances of getting some non-GPLd kernel code sharing from the Linux camp tho?

    Ask nicely, or be the person who does the development in the first place, and you can write a driver that runs on both Linux and BSD.

    For instance, the driver for the NCR/Symbios SCSI controllers is written by the same person for FreeBSD and Linux, and shares mostly the same code.

    Beyond code sharing, idea sharing is also a good thing, and if the design of Linux SMP and FreeBSD SMP are basically the same, it means that at least some bugs will be common, and it will be possible to eliminate them from both operating systems at the same time.
  • Because it's a plan, not a fact. It hasn't been done yet. When it is, it will surely deserv the first page.

    Mind you, Linux needed a section of it's own, because much of the stuff about it that comes to the first page really doesn't belong there.

  • Actually, Peter Wemm is core; he just happens to work at Yahoo!. Jayanth's last name is "Vijayaraghavan." And I was there for the first day.

    -Ed
  • This is one thing FreeBSD definitely needed work on and it looks like SMP is going to be a complete reality!

    Sure SMP has been available since the 3.0 branch, but it definitely needs to be improved.

    I wonder with all of the changes, how scalable will the SMP kernel be compared to Solaris (SPARC and x86), Digital UNIX and AIX? I hope this will also help out SMP on OpenBSD... just think... one processor handling the OS and the other processor handling all of the encryption calls!!!

  • That's *NOT* the general plan. That's just Dillon's part in it.

    And, just to correct something in the article, that's not "FreeBSD core team". Dillon isn't core, for instance. :-)
  • Can it be assumed, then, since Apple was involved, that this stuff will make it into Darwin and Mac OS X?

    Yay! SMP on quad G4 boxes!

    --

  • I've been waiting for this, I don't learn enough on a system that doesn't crash very often.

    BRING IT ON!!!

    --
    Eric is chisled like a Greek Godess

    • Mike Smith, BSDi, FreeBSD project, hardware, iA64 port

    Uh. Is this for real? Is there an IA64 port in the works? I've never heard that this has been mentioned before. Looking at the CVS now, I see that it's got an src/sys/ia64 subdir, but that subdir seems to be rather empty. Does anyone have any info on this?

  • Actually Matt Dillon's proposed SMP architecture is basically the same as the one in Linux 2.2/2.4 :)

    The page in question doesn't fully describe the architecture planned for FreeBSD SMPng; in, for example, the 2000-05-21 through 2000-05-28 freebsd-arch archives [freebsd.org], there's a lot of discussion, including this "short summary" note [freebsd.org], which start out saying:

    What is being proposed here is a major kernel architectural change. The locking provided by SPLS in the traditional BSD kernel goes away and is replaced by mutexs. This model is very different. Interrupts do not in general get blocked. When interrupt service code needs access to some piece of data which is actively being modified by what is traditionally thought of as the "top half" the interrupt thread will block at that point. The finer grained the locking the less chance of a collision, but the number of locking operation goes up and a price has to be paid.

    I assume that this is still the intent (I think I saw other stuff in "freebsd-arch" indicating so).

    You might want to checkout the "freebsd-arch" archives going back to May, and the "freebsd-current" and "freebsd-smp" archives from 2000-06-18, for more information; here's the top-level page for the FreeBSD mail archives [freebsd.org]. There's a note in the "freebsd-current" archives (I'm loath to give a link, as the current URL, I suspect, will become invalid when the next weekly(?) archive rollover occurs; check out "freebsd-current" for 2000-06-19, looking for "HEADS UP: Destabilization due to SMP development", from Jason Evans) that says:

    Greg Lehey will be working on the initial cutover to interrupt threads (as well as the lazy interrupt thread context switching code later on). spl()s will go away as soon as interrupt threads start working. Once interrupt threads are working, most of the remaining work of threading the kernel will be able to go on in parallel.

    I forget whether there were any messages discussing interrupt threads.

    Does the 2.2/2.4 Linux SMP implementation handle interrupts in a fashion similar to the one proposed?

  • IA64 (Score:1)

    by dfr ( 30895 )
    I created the ia64 directories in CVS so that I can generate patches easier. I'm currently roughing out the kernel port to ia64 and I expect to commit code over the next few months.
  • Look also at

    That doesn't work right now; I don't know if that machine and its HTTP server are being kept up 24/7 (the machine is pingable, but it refuses connections to port 80) - if not, it might be worth looking into putting it somewhere else as well. (Or does that machine have a dynamic IP address, and is ns.dyndns.org not giving me its current IP address? The address it's giving me is a Pac Bell Internet ADSL address.)

  • That URL does discuss other stuff. But, still, it is not a general overview.

  • Who attended? (Score:3)

    by dcs ( 42578 ) on Thursday June 22, 2000 @05:08PM (#984544)
    For those wanting to know who was there, here is a list (I copied this from someone else, so don't blame me for errors or jokes):

    Participants were:

    • Don Brady, Apple Computer, File systems
    • Ramesh, Apple Computer
    • Ted Walker, Apple Computer, network drivers
    • Jeffrey Hsu, FreeBSD project
    • Chuck Paterson, BSDi, Chief developer
    • Jonathan Lemon, Cisco, FreeBSD project
    • Matt Dillon, FreeBSD project VM, NFS
    • Paul Saab, Yahoo!
    • Kirk McKusick
    • Peter Wemm, Yahoo!
    • Jayanth, Yahoo!
    • Doug Rabson, FreeBSD project, Alpha port
    • Jason Evans, FreeBSD project, kernel threads
    • David Greenman, FreeBSD project, chief architect
    • Justin Gibbs, Adaptec, FreeBSD project, SCSI, 0 copy TCP
    • Greg Lehey, Linuxcare, FreeBSD project, storage management
    • Mike Smith, BSDi, FreeBSD project, hardware, iA64 port
    • Alfred Perlstein, Wintel, FreeBSD project
    • David O'Brien, BSDi, FreeBSD project, compilers, binutils
    • Ceren Ercen, Linuxcare, Daemon babe

    Look also at http://ziplok.dyndns.org/msmith/SMPng/ [dyndns.org].

  • FreeBSD has had SMP for quite a while as well.

    Contrary to what many may say, FreeBSD does NOT have SMP. It does in fact have multiprocessor support, but it is not at all SMP. It is of the "giant kernel lock" form, meaning that one processor handles all of the kernel time, and the other handles all of the userland time. This is not at all symetric, and thus, not SMP. It seems to actually work quite well on dual board systems, but it certainly would not scale well to a quad or higher configuration (only the first two processors can be used).
  • If anything this may be a good opportunity for Linux and FreeBSD to cooperate and share some code and ideas...

    What are the chances of getting some non-GPLd kernel code sharing from the Linux camp tho? It's an impossible sell to add GPL to the BSD kernel.

  • I hope this will also help out SMP on OpenBSD... just think... one processor handling the OS and the other processor handling all of the encryption calls!!!

    No no no. That's what encryption accelorator cards are for. And OpenBSD already supports them. Besides, that isn't semetric, and thus, is not SMP.
  • Well, not exactly. They use a Mach kernel, so they can't use FreeBSD code, but it has some of the same issues wrt to spl and locking.

    They do plan having kick-ass SMP, of course. That's a requirement nowadays.
  • It's possible that only a small amount of information has trickled through to /., but I can't be bothered to check. Interrupt threads are a natural consequence of removing spl protection: instead, we need to be able to block interrupt execution, which requires a minimal context.

    We're still working on the implementation details, but we're planning to have up-to-date information available on Jason Evans' SMP web page at http://people.freebsd.org/~jasone/smp/. If you're interested in participating actively, join the FreeBSD-smp mailing list.

    Greg

Slashdot Top Deals

FORTRAN is not a flower but a weed -- it is hardy, occasionally blooms, and grows in every computer. -- A.J. Perlis

Close