Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×

Understanding OS X Kernel Internals 199

jglidell writes "The OS X kernel has been in the news alot this past year, whether it's why its slow, Mach/micro-kernel makes it bad, it's going closed source and what not. Amit Singh has put up a new presentation on the innards of OS X. It does a pretty good job of summing up the OS X kernel architecture, and has some pretty detailed diagrams... for instance they show that there are so many process/threads layers in OS X. So if you are in the mood for doing some OS studying then head over."
This discussion has been archived. No new comments can be posted.

Understanding OS X Kernel Internals

Comments Filter:
  • huh? (Score:2, Insightful)

    by Aussie ( 10167 )
    whether it's why its slow

    What the hell does that mean ? Editors drunk ?
    • Parse it out:

      The OS X kernel has been in the news alot this past year, whether it's:
      -why its slow,
      -Mach/micro-kernel makes it bad,
      -it's going closed source
      -and what not

      make sense now?

      The sentence sucked, but it made sense in a bad grammar sort of way.
    • Re:huh? (Score:2, Informative)

      by Ant P. ( 974313 )

      It might make more sense in this format, and without the grammar error:

      ...in the news alot this past year, whether it's:

      • why it's slow,
      • Mach/micro-kernel makes it bad,
      • it's going closed source
      • and what not
      • Re:huh? (Score:4, Funny)

        by M. Baranczak ( 726671 ) on Monday May 22, 2006 @12:47PM (#15382048)
        Nope, it's still gibberish.

        whether it's why it's slow

        Well... why is it slow?

        Mach/micro-kernel makes it bad

        Debating the pros and cons of Mach is a valid topic, but a phrase like this is so vague that it's meaningless.

        it's going closed source

        OK, that one's intelligible. But then we come across gems like this:

        for instance they show that there are so many process/threads layers in OS X.

        A small request for submitters: Take a minute to actually proof-read your summary. I'm not even talking about simple typos, or the correct use of "you're/your" - those look ugly, but most of the time people can still figure out what you meant. Just ask yourself: will these words make sense to a moderately intelligent English speaker who's not on a meth bender?
    • Re:huh? (Score:3, Interesting)

      by jaysones ( 138378 )
      "Alot" isn't even an actual word.
    • Whether the news story is about why it's slow, or so on. You fail reading.
  • Needs more editor. (Score:4, Insightful)

    by dajobi ( 915753 ) on Monday May 22, 2006 @08:28AM (#15379687)
    "alot"
    "whether it's why its slow"
    "they show that there are so many process/threads layers in OS X."

    Do the editors even look at submissions any more? Or to put it another way, is our children learning yet?
    • by OECD ( 639690 ) on Monday May 22, 2006 @08:43AM (#15379803) Journal

      Do the editors even look at submissions any more?

      I'm afraid they do. I think the problem is that they're not as skilled in writing english as they are in writing PERL. (That's not a slam, by the way. I suck at PERL.)

      And before anyone goes on an "Off Topic" jag, it really does make a difference if the readers can understand what's being written. I stumbled over the "that there are so many" sentence a couple times trying to make sense of it. There are so many process threads layers in OS X that what? It slows it down? It's hard to program? Or is there simply a gee-whizz lot?

      Yeah, I know, I'm off to R the FA. I just wish I had a better idea of what's in there.

      • by gowen ( 141411 ) <gwowen@gmail.com> on Monday May 22, 2006 @09:48AM (#15380325) Homepage Journal
        I think the problem is that they're not as skilled in writing english as they are in writing PERL.
        I've seen slashcode.

        I think the problem is that they're exactly as skilled in writing english as they are in writing PERL.
      • That's not a slam, by the way. I suck at PERL.You speak of this as if it's a bad thing...
      • Do the editors even look at submissions any more? I'm afraid they do. I think the problem is that they're not as skilled in writing english as they are in writing PERL.

        Then maybe the good folks OSTG should consider hiring people appropriate for the jobs they're supposed to do.

        Honestly, I suck at PERL as well - I would never consider writing something in it, put it up for all to see and not expect to get torn to shreds by people who actually do know PERL, especially if I were getting paid to do so.

      • it really does make a difference if the readers can understand what's being written.

        Ramen to that. Of course, it doesn't just apply to the editors here on Slashdot, but to many posters as well (needless to say, though, the editors should be expected to know better English than the posters). I don't know if it's just me, but it has definitely made me enter a different reading mode when reading on Slashdot than on most sites out there, where I just scan for keywords in each sentence, rather than looking at

    • Me fail English? That's unpossible!
    • "whether it's why its slow"

      This one is actually grammatical, just awkward. "whether it is why MacOS X's kernel is slow, or ..."
    • actually, you know what's really interesting? That "whether it's why its slow" thing he's got in there is gramatically correct!!!

      It makes no sense to me because the sentence peters off, but it's the correct usage of it's and its. That sentence needs to be seriously reconstructed but the first two uses of it's and its in it are correct. The third one "it's going closed source" should be "its going closed source". But 2/3 is amazing for a slashdot post.
  • by thogard ( 43403 ) on Monday May 22, 2006 @08:35AM (#15379740) Homepage
    I have a small program that mmaps a bit of code and then points the program counter at it. Everything runs fun until a OS call happens. I've heard that Mach allows user land programs to install their own OS calls but I haven't seen any example code to do it and I suspect such a feature isn't in OS X. I've hunted through the source and I while I could write my own system call and compile it in, there should be an easier way. Can anyone point me in the correct direction?
  • Terrible summary. (Score:3, Insightful)

    by IANAAC ( 692242 ) on Monday May 22, 2006 @08:37AM (#15379760)
    I could barely get through the summary.

    If English is a second language for the submitter, fine. But good grief, do you suppose one of the PAID editors could have done just a bit of work to make the summary more readable?

    • '' If English is a second language for the submitter, fine. ''

      Very unlikely. Look at the choice of words, things like "innards", "head over". This is written by someone who knows the language very well, but is simply too uneducated or too lazy to learn how to write correctly.

      People who learned English as their second language very rarely use _bad_ English. They may have limited vocabulary, and you may spot typical mistakes that may even let you identify where someone comes from, but they won't get "their",
  • by Logic and Reason ( 952833 ) on Monday May 22, 2006 @08:46AM (#15379821)
    Before anyone starts spouting off again about Mac OS X being "slow by design" or somesuch, read this article by an Apple engineer [ridiculousfish.com] that investigates those claims.
    • That was a very good link. The comments where also very interesting.
      The author did address the Malloc issue well.
      What I got from the comments is that the author really did fail to address the issues that OS/X seems to have with the speed of some function system calls and or the speed of process and thread creation.
      It could be that OS/X isn't as well suited for HPC applications and some server application as Linux is.
      I do think OS/X is a very good OS. Just like Linux and Windows it isn't perfect and could im
    • There's plenty more.

      There's no doubt in my mind X is many times slower than it needs to be. Most of it is in the kernel though, not the call site.
      • You are incorrect, sir.

        It is a trivial experiment to initially cache the vp for /dev/null and /dev/zero, and then turn any reads or writes from either around immediately in the first function called out of the sysent[] table as soon as you see an fd pointing to one or the other, and never enter into the rest of the kernel. Then you can run the lmbench "system call speed" tests, with everything *but* the call site overhead factored out.

        The real problem here, though, is the perception that system call trap s
    • It's a good article. I wonder why OSX isn't compiled with a larger heap threshold, though? I'd do with a 2x performance increase on common operations even if it cost more memory (in the form of fragmentation). My only guess is that in real world usage this is not common, and thus it wouldn't improve real-world performance much?

      Cheers.
      • '' It's a good article. I wonder why OSX isn't compiled with a larger heap threshold, though? I'd do with a 2x performance increase on common operations even if it cost more memory (in the form of fragmentation). My only guess is that in real world usage this is not common, and thus it wouldn't improve real-world performance much? ''

        It is _not_ a common operation.

        As that article explained, the developers of the software in question could have used Shark (comes for free with every Macintosh), and within 20 s
        • Yeah, that was my guess; that it wasn't common in the real world.

          I wonder how much research there has been as to what the optimal size for the heap threshold is. It's just interesting that the malloc implementations differ so much. It sure makes sense to distinguish between small/fast allocations and larger allocations. But is 35K really optimal? Maybe it is. Do they publish data on this anywhere?

          Cheers.
  • Ad (Score:5, Informative)

    by AstrumPreliator ( 708436 ) on Monday May 22, 2006 @09:03AM (#15379961)
    I looked at the "presentation" and no, it doesn't do a very good job of explaining anything. Maybe combined with an extensive lecture to explain what the hell he's talking about would make it a bit more clear. From what I saw it was basically just enumerating the different components. Then I noticed the second to last slide. It's basically an ad for a book coming out.

    Maybe it's just me though. Did anyone else find it extremely enlightening?
  • by Beefslaya ( 832030 ) on Monday May 22, 2006 @09:07AM (#15380004)
    As the purchaser of a brand new Core Duo Mini, (my first Mac, I feel "as happy as a little Gurlll!") I noticed that my system out of the box with 512 of RAM was dog slow when you start loading iPhoto, or any more then 2 apps.

    Initial startup yielded a smoking fast web browser, and other single line items.

    I purchased the 2GB Ram upgrade (not from Apple at 600 USD, 280USD from Crucial) and I noticed such a difference, that I couldn't understand WHY they would even consider shipping that little silver wonder with less then 1GB of RAM.

    It's not the kernel, it's the apps... They just don't give enough power to the off the shelf machines to support the great apps that come with it.

    Vive le Mac... Thanks for putting excitement back into computing for me.
    • by caseih ( 160668 ) on Monday May 22, 2006 @10:18AM (#15380632)
      I think much of OS X's ram-hungriness comes from the fact that outside of the system frameworks, there is very little utilization of shared libraries among the different applications. Each app bundle is largely self-contained with its own shared libraries. Granted most apps that ship with OS X (from apple) just access the shared frameworks in /Library/Frameworks and have few other dependencies in their bundles. But start adding apps like MS Word, Firefox, OpenOffice, etc, and you'll start having multiple copies of various libraries loaded. The app bundle system is very simple and reliable, but because of the shared library issue, you'll always need more ram when running these apps on OS X than Windows or Linux.

      Definitely 1 GB is a minimum amount of RAM needed for OS X Tiger these days. That is quite sad when you think about it, but RAM is cheap so I'm not too concerned about it. Apple has always shipped their machines short on RAM, hoping you'll pay ridiciulous amounts of money for their official RAM upgrades.
      • Not to be a total Apple fanboy but all mainstream computer suppliers sell PC's with half the amount of RAM that's usually needed. When Windows ran fine on 128 MB, you got 64. Now you usually get 512 MB, but XP SP2 is slow with less than a gig. Especially if you're playing games, but also using regular apps.
      • Not sure why my post was rated funny, but oh well. Karma is karma.
        • Not sure why my post was rated funny, but oh well. Karma is karma.

          Being modded "Funny" doesn't improve you karma anymore. Your post seems to indicate that you didn't know this, but I'm not sure. Anyhoo, here's the relevant FAQ [slashdot.org]:

          What is karma?

          Your karma is a reference that primarily represents how your comments have been moderated in the past. Karma is structured on the following scale "Terrible, Bad, Neutral, Positive, Good, and Excellent." If a comment you post is moderated up, your karma will rise.

      • Perhaps if those applications actually leveraged Cocoa's AppKit Frameworks, Core Data, Core Imaging, etc., then you'd see drastically smaller app bundles and more shared use of built-in Cocoa Frameworks.

        Since they are Carbon based expect them to be bloated.

        When Apple replaces Finder and other critical sections of their application base with pure cocoa applications then perhaps we'll see more improvements as we should have seen.
    • I purchased the 2GB Ram upgrade (not from Apple at 600 USD, 280USD from Crucial) and I noticed such a difference, that I couldn't understand WHY they would even consider shipping that little silver wonder with less then 1GB of RAM.

      And this is exactly what you should have done. Apple ships their consumer boxes with way too little RAM (they always have,) but the upside to that is you can just go elsewhere and buy it cheaper than Apple is willing to sell it for.

      I wouldn't fully judge ANY computer's speed unles
    • "I noticed that my system out of the box with 512 of RAM was dog slow when you start loading iPhoto, or any more then 2 apps." You know, for the first several hours of uptime after starting Tiger for the first time, depending on how much data you have, the Spotlight is indexing all your drives in the background and the system is SLOW AS MOLASSES. Like, painfully so. But it speeds back up after it finishes all that initial indexing.
    • You also have to remember that the Mac mini has integrated graphics which uses some of the memory. I've heard it uses about 80MB of your memory. But I agree, it needs at least 1GB to run smoothly.
    • The Core Duo/Solo Mac Mini and MacBooks run faster if you pair RAM sticks due to the memory architecture. This is most felt on the Minis and MacBooks (non-Pro) because they use system RAM as video RAM. From the factory all these Macs come with single RAM sticks.
    • Kernel and Kernel Theory Aside...

      Most Apple applications themselves tend to be a bit 'bloated'. No matter how fast the kernel is, you have a bit of a bloated GUI construct (especially in terms of RAM Usage) then add on the RAM used by some of the built in applications, and ouch.

      And no, not all of Apple application are bloated, safari isn't bad in terms of size and performance in comparison to some of their other creations like iPhoto, etc...

      You can almost pick through the applications included on OSX and se
    • Vive le Mac... Thanks for putting excitement back into computing for me.

      Mac means "pimp" en français. Thought that was rather funny.

  • Closed? (Score:5, Insightful)

    by ShadowBottle ( 663193 ) on Monday May 22, 2006 @09:27AM (#15380149)
    Riiiight. Just because some idiot alarmists say that the kernel has gone closed when it simply just hasn't been released yet, the media and clueless bloggers start crying that it's gone closed source.
    "Well... it hasn't. It's still open. IT JUST HASN'T BEEN RELEASED YET.
    OSNews is reporting that Ernest Prabhakar, Apple's Open Source and Open Standards product manager, has stated in the Fed-Talk mailing that Apple has not actually closed Mac OS X's Darwin kernel for the Intel version of the OS; they simply haven't released it yet. Speculation about Apple closing the kernel arose from the fact that other non-kernel Darwin sources actually have been released, and the previous PowerPC-based kernel is still available as open source as well.Ernest wanted to make sure that tech media didn't confuse 'speculation' with 'fact'. A good lesson we all could benefit from...."

    God damn alarmist idiots.
    • Comment removed based on user account deletion
      • Comment removed based on user account deletion
        • Comment removed based on user account deletion
          • Comment removed based on user account deletion
            • Comment removed based on user account deletion
              • Comment removed based on user account deletion
              • ...my argument makes sense...

                Uh, you don't appear to be presenting an argument, you seem to have an unsupported opinion. By the way, your position (not argument) makes sense to you. Yet you have at least two people who appear to disagree with the "logic" which lead you to your position, not that that really matters.

                ...you don't have a counter-argument.

                He doesn't need one. He's merely presenting what he sees as relevant facts to the seemingly unreasonable.

                ...by delaying and refusing to confirm it will be

                • Re: (Score:3, Funny)

                  Comment removed based on user account deletion
                  • After re-reading your posts, and the responses, I don't disagree with you. I interpreted your statements to be supporting Yager's interpretation as fact.

                    Yager's speculation as to why they might close it sounds viable, but Prabhakar says that it's merely speculation. Which it is. Yager's assumption doesn't seem to address the possibility that Apple might be changing from XNU to something else entirely, which has been continually speculated for years now. Yager also ignores the possibility that they migh
          • Apple is notorious for playing their hand close to their chest. If they want you to know something officially, then they'll tell you. If they don't they won't. Speculation about Apple has never gotten people very far...
            • Comment removed based on user account deletion
              • Wow. What a horribly sad little straw man you've constructed to support your interpretation of Apple's non-disclosure. You clearly don't understand how this company works. There has been zero substantiation of whether they will close the source or not. The analysts are speculating, which is what they do.

                Apple has been known, on many occasions, to not reveal free improvements to hardware until it was in their customers hands. Which is just as unimportant as your argument.

                Patience is a virtue my friend
              • If you had called Apple two weeks ago because you'd waited a month for you iBook to arrive, and asked if the iBook had been discontinued, they wouldn't have mentioned anything about the fact whether it's still in production or not.
  • by ElitistWhiner ( 79961 ) on Monday May 22, 2006 @10:36AM (#15380828) Journal
    As an ex-NeXT developer, the historical speed bumps behind this architecture are directly related to code density. NeXTSEP ver 2.0 was nicely running on 25mHz. NeXTSTEP ver 3.0 suffered performance on 25mHz compared to ver 2.0 because of the additional kernel overhead resultant from code densification.

    With every ver. release through 10.4.x MacOS X, mach/BSD layer exhibits funtional improvements with speed increases of the processor CPU and latent performance behaviors from the additional kernal overhead added by code complexity and densification.

    Prima Facia evidence to the 4X speed improvement in performance from Apple's new Intel CPU bears witness to the limits of the kernal architecture.
  • I read the Flash presentation. It's at such a gross high level and lacks any details other then the names of some modules. There is no new information here. OK there are lots of parts and it looks complicated but Linux has all those parts too (except for the bagage that is needed to support old Mac OS9 aps)

    My opinion is that mac OSX is very well designed if you beleive that in the future there is be more and more "cores" inside most notebook and desktop computers. OSX is well setup to take advantage

God made the integers; all else is the work of Man. -- Kronecker

Working...