Slashdot Mirror


FreeBSD SMPng Interview with Scott Long

animus9 writes "There's an interesting interview with Scott Long over at the ONLamp.com. Scott explains the difference between the various locking methods, and the current status of SMP in FreeBSD 5. He also compares the new SMP implementation with that of FreeBSD 4.x, NetBSD, DragonFly, and Linux. Other items touched upon include scalability, the status of KSE & ULE, and much more."

13 of 76 comments (clear)

  1. BSD is starting to look as a viable alternative by Anonymous Coward · · Score: 3, Funny

    I must say that reading this interview only reinforced my gut feeling that FreeBSD and other BSD variants start to look as a viable alternative to Solaris and Linux. This is consistent with the attitude in my company. To make a long story short, I received the email first thing in the morning from the IT department. Our network would be undergoing a major overhaul to correct the ad hoc growth it had experienced in the last year, and starting next week Internet access would be sporadic. There would also be a new firewall and security measures, replacing the old OpenBSD system I'd managed to get installed last Spring. Happy for the heads-up, I went to work right away to make sure Linux had no place on our network. This was not the first time that I had faced this threat.

    One day about a year ago our network guy gets asked to draw up firewall plans for this subnet of servers we have. Our network guy was your typical GNU-slinger save that he had a cascade of flowing hair down the back of his head and not a beard hanging from his face. And yeah, you can guess what he thought those firewalls were gonna run. Fast forward two days. I'd caught wind of the plans and had charts, graphs, and comparisons written up detailing OpenBSD and Linux security. Since this GNU guy had a mullet and dressed like a slob, I got taken seriously. Not to mention my data, impenetrable by any hippy "logic." OpenBSD was the more secure, even to the beancounters and idtiot management. So thanks to me, our firewalls happily run OpenBSD and not Linux, which would have buffer-overflowed into no-man's land every other hour. The Open Source Mullet gives me a lot of dirty looks lately.

    Since the Open Source Mullet had been canned, a new threat had arisen at my workplace: the Fat Perl Hacker had assumed most of the Open Source Mullet's system and network administration duties, and it was no mystery to anyone at my workplace that he had a hard-on for Linux tucked away under his enormous, cascading gut. Since he was a major suck-up and workaholic, he had a lot more credibility than the Open Source Mullet this would be a real challenge for once. Dealing with the Open Source Mullet had been cake.

    That night, I went to work on my strategy. First, I would document the changes in Linux and OpenBSD since a year ago when we last went with a security plan. Linux was still at version 2.4, while OpenBSD had raced from version 2.8 to 3.1 a major revision! This was good so far, and I included the relevant diffs for each. I wondered what the Fat Perl Hacker was up to and pushed ahead with my preparations.

    Tuesday morning, I went to talk with the VP of Operations, who had final say on the network project. I wouldn't leave anything to chance. But after chatting with him for a few minutes, I learned of a major monkey-wrench I hadn't expected: instead of a Unix firewall system, he was planning on installing a dedicated firewall box running Windows XP. Thankful for my fortuitous social engineering, I went back to my desk and began making over my strategy to deal with this new threat. Not only would I have to deal with Linux, I'd have to eschew the Windows option now.

    Sitting in front of my iBook after work, I realized that taking on Windows XP in the same manner I was going to deal with Linux would be foolish if not wasteful. Obviously the Windows option was not about numbers, anecdotes, or experience. It was a bean-counting decision and all of the security statistics in the world wouldn't matter. Since I hadn't the foggiest about how our accountants viewed the whole operation and didn't have time to learn, I'd have implement a rapid-fire real-life assault on the Windows box, which was sitting on the VP's desk awaiting its place on the network. It was time to put on my Black Hat, and that night I stayed up until 02:00 researching Windows XP vulnerabilities. Linux would have to wait.

    With just two days before the network changeover was to take place, I marched into work Wednesday morning knowing

    1. Re:BSD is starting to look as a viable alternative by SlashCrunchPop · · Score: 2, Funny

      Now try to visualize that story with FreeBSD's Scott Long (2nd on the left) and his Linux mullet-sporting namesake counterpart. I don't know about you, but I think Linux has finally found its poster guy, he and Tux look so happy together in that photo, don't you think? Of course, they'll also need a new slogan to go with the new poster, so I propose "Linux: the bare essentials open source OS. Who do you want to get friendly with today?"

  2. Re:Waaaa? by MPHellwig · · Score: 2, Insightful

    "First they ignore you. Then they laugh at you. Then they fight you. Then you win." by M. Gandhi.

    This phrase has often be used to describe the MS Windows - Gnu/Linux relationship.

    It seems to mee some of the Linux zealots forgot there heritage.
    Forgot that Linux is just a kernel without GNU.
    Forgot that there could not have been there, where there are now, without the BSD licensed software.
    Forgot what free software was all about.

    I'll stick to my BSD's at least there is some real progress there without the attitude.

  3. Sleep locking, spin locking by Julian+Morrison · · Score: 3, Interesting

    This article discusses FreeBSD's preference for sleep locks as versus the spin locks in Linux.

    Anybody know why Linux went for the spin lock approach? What are the relative merits?

    1. Re:Sleep locking, spin locking by Anonymous Coward · · Score: 5, Informative

      Linux uses spinlocks but only when it is certain that it will be released very quickly. It boils down to efficiency. That is because if a lock is held for a very short amount of time, it is more efficient to wait for it than to switch tasks. The Linux design is really to minimize lock hold times by doing as much work as possible without holding locks, and then checking to make sure that things are still right. This technique has allowed Linux to scale linearly up to hundreds of processors. In practice, Linux's SMP implementation has proved to be one of the best.

    2. Re:Sleep locking, spin locking by glasn0st · · Score: 4, Informative

      If I recall correctly, FreeBSD also uses this strategy when the kernel is compiled with ADAPTIVE_MUTEXES which is now the default in 5.3.

      --
      ( ^_^)/
  4. Slashdot confirms: Apache is dying! by bitflip · · Score: 2, Funny

    There's been seven BSD articles on slashdot since the beginning of the year.

    And apache? Nothing. Last year, just after Christmas, a bit about test mod_perl (and that's barely apache).

    BSD is doing fine. Apache is dying. ;)

  5. Re:Waaaa? by LWATCDR · · Score: 2, Insightful

    "I'll stick to my BSD's at least there is some real progress there without the attitude."
    Which BSD is that? From what I have seen BSD is not lacking in attitudes.

    --
    See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
  6. meh by ArbitraryConstant · · Score: 2, Insightful

    I disagree with zealotry in any form, and that includes ignoring Linux as an alternative when it's actually pretty decent at a lot of things.

    However, the 2.6 kernel has been a mess from day one. I'm used to new versions being a bit buggy, but the kernel developers keep adding new bugs.

    First, there was that memory leak with burners. Now more recently they've been moving to libata, and that prevents SATA and PATA drives from being used at the same time on my system because libata does not yet support PATA drives, and all the ATA controllers are on the same chipset. I've had to install an old Promise ATA controller to have a CD drive on my system.

    They say it's up to the distributions to stabalize their own kernels, but the distributions clearly don'thave the resources to do that.

    Time to fork 2.7 guys!

    --
    I rarely criticize things I don't care about.
    1. Re:meh by setagllib · · Score: 2, Interesting

      The first time I booted 2.6.3 (mainline, under Slackware, previously 2.6.2 with less problems) every file opened for writing would be truncated and never written to. My entire home dir was mangled and it took a very long painful sitting of deleting and re-configuring before things worked again, and even then there were flake outs. I never booted 2.6.3 again.

      2.6 then had some large changes (nptl, new SCSI subsystem without warning, etc.) and now at 2.6.10 seems to be at least sort-of stable, but there are compile warnings in wireless drivers I think are actual mistakes and am glad I don't have that hardware. On the other hand, and this is a big thing in favor of the BSD style kernel configuration, with 2.6.10 a certain magical combination of kernel options left me without a console outside of X (and no, I did not ask it to use serial console), and reconfiguring from scratch was the only thing that fixed it. I still have not been able to reproduce this (but remember it happening with an earlier kernel, might have been a 2.4) or even figure out what option/combination caused it. I mean, that's pretty f#ed up.

      --
      Sam ty sig.
    2. Re:meh by setagllib · · Score: 3, Interesting

      Bzzzt try again, troll. NPTL has been in Linux since the middle of the 2.5 development cycle.

      /usr/portage/dev-libs/glibc/glibc-2.3.4.20040619-r 2.ebuild
      # Minimum kernel version we support
      # (Recent snapshots fails with 2.6.5 and earlier)
      MIN_KERNEL_VERSION="2.6.5"

      Headshot. If it hadn't changed, there'd be no reason that newer user-land nptl libraries wouldn't work with older kernels. Read up before you think you're fighting 'trolls'.

      And there was no "new SCSI subsystem" in 2.5 or 2.6 period.

      http://www.webservertalk.com/message841936.html
      Sorry, really bad wording on my part, based on some confusing Slash comments I read before. Hardly trolling, you'll notice.

      Linux does not cater for incompetant people

      No, I actually did check everything, and have been configuring and compiling Linux kernels with mostly success (except weird shit like this) for years. There's no magic to it, don't pretend to be a technical expect because you've never found a bug. Same goes for that "absolutely no idea when it comes to kernel coding" assumption: I am a coder and I do know when a warning is an error in disguise. By the looks of it the calling parameters of something internal changed (since this did not happen in 2.6.9) but not all drivers were updated, and nobody cared. If this is not the case, they should fix compile warnings: the BSDs do, because warnings left over in 'stable' branches signify lazy/careless developers (i.e. Linux contributors).

      Nice AC posting by the way, if you're going to make insulting claims against someone, do it with your own name or risk not being taken seriously. If I wanted to troll, which I don't, I wouldn't do it under my own name. From this perspective we gather that you're the troll and I'm making honest observations. Have a really bad day, you deserve it.

      --
      Sam ty sig.
  7. Re:SMP BSD by setagllib · · Score: 2, Interesting

    OpenBSD basically needs a bigger contributing (at least PRing) user base. So does NetBSD of course. The number of developers is fine in both because they are talented and can work together (oppose thousands of Linux devs who still can't engineer for stability), but the user bases are too small to really test everything at once.

    Shame isn't it? With Linux stealing the spotlight all the other more deserving projects are left lacking users.

    --
    Sam ty sig.
  8. Re:Bullshit by setagllib · · Score: 2

    Not my point actually. My point is that you insist everything in Linux MUST be perfect, because it's Linux, and everything in BSD MUST be 'SUBSTANDARD', becuase it's in BSD.

    I am well aware of all the failures in FreeBSD 5. But it's SMP design is not sub-standard. There is no standard. Let's say there are 5 major free OS players that just about everyone can name: Linux, FreeBSD, DragonFly BSD, NetBSD and OpenBSD. Linux and FreeBSD have (different but conceptually familiar) mutex SMP models, and while Linux' one clearly owns the FreeBSD one hard, the design of FreeBSD's one is not too terrible... if they coded it right. They didn't. It has sub-standard code, not sub-standard SMP design. DragonFly has a much better approach with much better code, so while it beats FreeBSD 5, it's not made the 'standard' just by that. Net and Open have the giant lock so they are the worst players, but in practice they still beat FreeBSD 5 so design isn't everything.

    And why do you defend a driver being unpopular/irrelevant (not true if you realise not all machines in the world have GigE cards, or even the capacity to use them) as an excuse for it sucking? Why not just break support for all notamd64 architectures because they're not mainstream and modern enough? All those sparc, alpha, etc. guys should move up to amd64! Isn't that right? Same thing with firewire networking versus gige. Sure it's not even half the theoretical bandwidth, but that's no reason to ignore the possibilities and necessities it can have.

    I'm tired of this, I've been swatting away you trolls (who call me a troll, by the way) since morning. If you think Linux is the final solution to every software problem, you are now commanded to touch a computer again.

    Where's ulib? He can help here. Much more experience in troll squashing than I have.

    --
    Sam ty sig.