Slashdot Mirror
Understanding OS X Kernel Internals
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."
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?
"Alot" isn't even an actual word.
Alot of what youre saying makes good sense.
If you don't know what AltaVista is (was), get off my lawn.
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.
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 know that the original code, from NeXT, was Mach because there wasn't any choice. But in this day and age there are plenty of microkernels that actually perform well, even as a platform for full kernels. There's plenty of benchmarking for Linux on L4, and Linux on Exokernel. Both have minimal impact on performance. (L4 is usually 2-10%, Exokernel is similar.) Mach is a dinosaur. And since microkernels are small, with well-defined interfaces, porting to a more modern one should be relatively easy, even keeping backwards-compatibility of libraries. (You might need a mach emulator, or mach-on-top-of-l4 for a few mach-specific system calls, but that would hardly be a problem.)
So why hasn't apple done it?
You're assuming that the only market for software is medium to large enterprise. Autocad (which is made by a well known vendor) is used by tons and tons of architects. Since I've worked in IT support for a few architectural firms, I can tell you that most of them are comprised of small business of under 50 employees. I've used Autocad under Windows, however when I needed to use something to make some plans for a shed for my church, I used Sketch-Up, because there's an OSX native version.
Furthermore, most of the people that I've run across who are excited about virtualization are primarily interested in using it to run the existing Windows apps they own, and plan on replacing those with OSX native versions where available, and comparable OSX native apps where not available. The other major segment (where I fall into this equation)interested in virtualization, is the IT people who use/support multiple platforms.
Boot Camp is for games. Noone I have spoken with that knows about virtualization is seriously intersted in using it for anything other than games.
What?
I'm not understanding something...
This seems like Carly Fiorina Logic. If we stop making HP calculators, people will just buy handheld HP units with similar funtionality. It doesn't matter that the calculator group provides a substantial net profit for the company. If we stop spending all that money on supporting calculators and simply use the computer support people we already have... Think of the savings!!!!
When a group/division in a company that caters to a market makes the company lots of money, leave them alone. They're doing their job, pulling a PHB stunt in wall street business tactics will only hurt your company.
'' 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 seconds they would have found that they are wasting tons of time by allocating and deleting memory again and again and again and again and again. Note that for calls to malloc () to make any noticable difference in execution time, you must make an awful lot of them. So twenty seconds of observation plus two hours of tweaking their code would have made their software substantially faster _on every_ platform.
Typical code has few large allocations, which stay around for long time, and possibly a huge number of small allocations that get allocated and freed very quickly. So an implementation does the small allocations itself (because it is quicker) and leaves the large allocations to the OS (because that helps with fragmentation), just as MacOS X does.
Well, you're both kinda right.
Certain Power Macintosh models, usually the higher end ones, could use matched pairs so that you could interleave memory pages. If you went that route, supposedly you could squeeze out some more system performance. If I remember right, Apple claimed you could gain up to 20% more total system performance on the PowerMac 8500/9500 systems by activating memory interleaving. The only people that I remember doing this were heavy Photoshop users or serious Adobe Premiere video editors. Remember, this was about when DRAM was considered cheap at around US$12 per MB!
It didn't have to be from Apple, either. I remember setting people up with lots of Kingston SIMMs and DIMMs back then.
Otherwise, you could put any memory that fit (except ECC) in any slot order, and it would run fine that way, too.
- Semper Ubi Sub Ubi!
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.
Few, if any, current UN*Xes were "designed to have locks", but many of them (Solaris, Linux, FreeBSD, OS X) have made their locks finer-grained anyway; it's not as if you're stuck with all the consequences of the "design" forever.
What are some examples of this extra indirection? (Note that system calls are not redirected to userland servers.)
Windows personal computers (as opposed to servers) aren't intended to be single-user interactive systems?