Check out my latest product, BuildFactory
Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/globalfunctions.php on line 779
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/BLOG.php on line 170
kernel_task, it is as if i barely know you
Warning: Parameter 1 to NP_Geshi::event_PreItem() expected to be a reference, value given in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/MANAGER.php on line 331
Recently I've become a big fan of using Activity Monitor for fun and profit. Activity Monitor, just in case you aren't already aware, is like top(1) with pretty graphs and charts, and a swanky aqualicious interface, and will show you things like virtual memory usage, thread counts, a process' user id, CPU usage, and a lot of other things in 8-bit technicolor.
Fernando, infamous graphics designer (who just so happens to be responsible for the BuildFactory icon, and about anything else about bleep. that makes you say "man, that looks cool"), noted today that kernel_task has an obscene amount of threads, and takes up a decent chuck of virtual memory. So in my lack of any sort of infinite wisdom, I feel the need to explain this, since I of course, know everything about Mac OS X and mach internals (that's a facetious statement folks, look closely, I attempt to weave humour into my writing quite often).
A bit of background
Mach is one of the more successful stories in microkernel development, Mac OS X is based around the Mach microkernel, as well as the NeXTStep of old, as well as DEC's OSF/1, and IBM's frequently deceased OS/2 (at least for RS6000 machines). In accordance with the basic concept of a microkernel, Mach manages memory, and handles inter-process communication but not much else. The basics of Mach can be better understood by visiting the wikipedia page instead of the project page itself (about a decade out of date).
But wtf is kernel_task?
From my work with launchd(8) I understand enough about the lower level happenings of Mac OS X to tell you...kernel_task is not a "task" per se, but more....a representation of the microkernel itself. When Dave Zarzycki created launchd(8) for Mac OS X there was a culture of "reducing the daemon count" (probably still is, but we haven't exchanged emails in a while), so in order to get his launchd(8) project into the base operating system, he incorporating the functionality of init(8) which on a classical Unix (think FreeBSD) operating system, is more or less responsible for boot strapping the userland processes, and starting all the background daemons, as well as the ttys(5) that are needed to console access, etc. Being the first userland process, launchd(8) starts with PID 1, which means it's the userland process to end all userland processes ;). If you'll notice in Activity Monitor, kernel_task is PID 0, which most likely means that it's not userland related at all.
No seriously, wtf is kernel_task
Documentation on kernel_task is sparse at best, but from what I can glean from the darwin-drivers@lists.apple.com mailing list that I'm on, it seems to be the basic (virtual/)memory manager for Mac OS X on top of Mach. From the best I can tell, this is similar to the sigma0 concept with the L4 microkernel. There needs to be some underlying task on top of any microkernel (from the best of my understanding) to dole out resources, like pages of memory, to the userland processes. Unfortunately, I can't really find documentation for much about kernel_task, but I'm relatively confident in telling anybody that's read this far (all both of you!) that kernel_task is responsible for handling the allocation of pages of memory in the Xnu kernel (Mach+IOKit+whatever else Apple threw in), which would explain why it has an amazing amount of threads. There is however another process that shows up, the dynamic_pager which I'm assuming (feel free to correct me) handles the swap file nonsense for Mac OS X. Of course, something I'm unsure about is how related kernel_task and dynamic_pager are. It's quite possible that kernel_task and dynamic_pager work together of a Mach port, and when necessary, kernel_task runs out of available resources, it serves up memory from a swap file managed by dynamic_pager. That's pure speculation, but at least I'm not speculating about a bloody iPhone ;). (For what it's worth, on my FreeBSD workstation, PID 0 is reserved for the [swapper] task, which makes sense when related to the sigma0 concept, and kernel_task)
There are lots of cool underlying daemons and processes that handle a lot of the lower level things in Mac OS X, because in a conventional microkernel design, all that nonsense should be handled in userland. One of my personal favourites is blued(1) the bluetooth daemon, kextd(8) which manages the loading and unloading of kernel extentions (kexts they call them, man those Apple engineers are clever :-P). Other fun processes include coreaudiod(8), netinfod(8), and configd(8).
The internals of Mac OS X never cease to amaze me, but poke around yourself, and check out some of the latest sources from opendarwin.org
Update: For what it's worth, I've added a bit more on the latest post: Amit Singh puts kernel_task in it's place
[tags: apple, darwin, xnu, mach, l4]
Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/globalfunctions.php on line 779
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/ITEM.php on line 61
Replies
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
True, in regards to it being a task in terms of Mach, but the "tasks" that I was referring to were more 'userland' tasks, i.e. unix processes that are being executed in the userland address space.
But of course, I'm more than welcome to correction since I'm certainly not familiar enough with Mach (still have a lot of questions to answer for myself regarding L4), this is a good time for that NBC star to shoot across the screen with the twinkling sound and the banner "The More You Know" ;)
But of course, I'm more than welcome to correction since I'm certainly not familiar enough with Mach (still have a lot of questions to answer for myself regarding L4), this is a good time for that NBC star to shoot across the screen with the twinkling sound and the banner "The More You Know" ;)
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
You should make more clear in your article mac os X's kernel (XNU) isn't a microkernel.
But nice article although a bit short on details.
But nice article although a bit short on details.
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
Wow ... incredibly well written. And I think I can understand. Any more "details" and the average user's head would explode. Thanks for this!
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
Do you know where networking sits inside a microkernel? It seems to me like at some level a lot of this stuff that supposedly gets pushed into userland needs a way back into the kernel, otherwise you'd have direct userland to hardware interaction.
Awesomely informative, though.
Awesomely informative, though.
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
Referring to my new favorite book OS X Internals ... I/O Kit in our friend kernel_task houses the low level layers of OS X's networking. Apparently they're connected to the BSD networking code via a data link interface layer (DLIL). bsd/net/dlil.c . Specifically the DLIL is used for communication to the IONetworkInterface class. Thank you Mr. Singh!
Translation (as best I understand it), IONetworkInterface is the abstract interface to your ethernet card (for example), effectively hiding the device driver etc. It tosses packets to BSD by placing them in an input queue thread (the DLIL). These are then passed to their respective protocols, and placed in sequence. Ultimately the contents are passed to userland via a socket interface. Guru's out there, please correct me here.
Translation (as best I understand it), IONetworkInterface is the abstract interface to your ethernet card (for example), effectively hiding the device driver etc. It tosses packets to BSD by placing them in an input queue thread (the DLIL). These are then passed to their respective protocols, and placed in sequence. Ultimately the contents are passed to userland via a socket interface. Guru's out there, please correct me here.
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
"It seems to me like at some level a lot of this stuff that supposedly gets pushed into userland needs a way back into the kernel, otherwise you'd have direct userland to hardware interaction."
That is allowed, and if the CPU and I/O system can allow you to access a subset of the hardware from a userland task, it is actually a good idea.
If "only the micro kernel can touch hardware" then the microkernel has to have all hardware drivers, and isn't so micro.
If the micro kernel can be told "task X can fiddle with IO space Z" then task X can handle talking to the ATA chipset, and that is one less thing for the micro kernel to do.
It is also nice because for some hardware it would let you handle driver failure by killing the driver and restarting it (some hardware can't really be reset without a power cycle...and other hardware might be needed to handle reading the driver back into memory, so isn't a good candiate for resetting).
It is also nice because it lets you use more normal tools for debugging drivers, and also makes debug cycles faster and easier. Both of those should result in less buggy drivers (but might just result in more drivers written per unit time, or more chrome per driver).
That is allowed, and if the CPU and I/O system can allow you to access a subset of the hardware from a userland task, it is actually a good idea.
If "only the micro kernel can touch hardware" then the microkernel has to have all hardware drivers, and isn't so micro.
If the micro kernel can be told "task X can fiddle with IO space Z" then task X can handle talking to the ATA chipset, and that is one less thing for the micro kernel to do.
It is also nice because for some hardware it would let you handle driver failure by killing the driver and restarting it (some hardware can't really be reset without a power cycle...and other hardware might be needed to handle reading the driver back into memory, so isn't a good candiate for resetting).
It is also nice because it lets you use more normal tools for debugging drivers, and also makes debug cycles faster and easier. Both of those should result in less buggy drivers (but might just result in more drivers written per unit time, or more chrome per driver).
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
my main question is: how do you make it less memory consuming? i'm a new mac user and i find the machine to be quite slow, regardless of its claim to be "superfast"..
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
Write reply
This item is closed, it's not possible to add new comments to it or to vote on it
-jcr
Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 391
07:13PM,
Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/globalfunctions.php on line 1112
Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/globalfunctions.php on line 1132
13/07/06