I'd just like to know what it is that kernel_task is responsible for. Also, what's an acceptable maximum RAM and CPU use for it?

  • 1
    Best to measure your RAM and CPU use after a safe boot to get a measure of what your system runs at when idle.
    – bmike
    Jan 18 '12 at 0:47
  • 2
    According to Tyler, it is a "representation of the microkernel itself." If you want a more specific answer, he goes on to say that "it seems to be the basic (virtual/)memory manager for Mac OS X on top of Mach." You'll be hard pressed to find a definitive answer unless you speak to a high-level Apple engineer. The public has only pieced together this process. Source: bleepsoft.com/tyler/index.php?itemid=43
    – user10355
    Jan 18 '12 at 2:46

The kernel task is special since it's an entire operating system / micro kernel based on Mach 3.0. It abstracts most of the core hardware, timing, message passing and memory handling.

What most people notice in Activity Monitor is that kernel_task accumulates all the CPU time for input/output (i/o) processing delays and calculations as well as scheduling overhead of processes and threads. Similarly - it accumulates all memory allocations that are not in the user space. On the 2014 and newer Macs, this task exists to throttle the CPU - when the temperatures in the processor are too warm, kernel task is assigned "no work" and shows high CPU busy to let the processor idle and not overheat the computer. This is most noticeable on the portable line - especially the MacBook without any sort of fan or blower to cool the processor. Apple warns of this to potential kernel programmers in "Why you should stay away from programming in the Kernel" that disabling cooling will cause permanent irreparable hardware damage.

To summarize, kernel programming is an immense responsibility. You must be exceptionally careful to ensure that your code does not cause the system to crash, does not provide any unauthorized user access to someone else’s files or memory, does not introduce remote or local root exploits, and does not cause inadvertent data loss or corruption.

If you watch it after a reboot you will see it starts with minimal RAM and CPU needs and instead grows only when other programs run and need the system services.

To slim it down, shut off unneeded ports (WiFi, bluetooth, etc... ) as well as idle / unused programs. If things don't settle down, consider rebooting to ensure no task is stuck or leaking memory. If you have programs doing real work, they will cause the kernel to use both memory and processor time - just watch as you start things to see which other programs are causing this behavior. It's rarely an issue with the kernel - even with badly performing programs - that can't be solved by logging out and back in again. The kernel_task cleans up well and generally takes care to only use the resources needed by the workload.

  • Thanks! Would you say 700-750 MB of RAM is acceptable for it? I have plenty free, but I'd like to know if there's anything I should do anyway.
    – Tuesday
    Jan 18 '12 at 0:48
  • Not necessarily. On my main MacBook Pro, it can swell to 2 GB at times when I'm really running a lot of involved programs. Even then, I don't often have to reboot but once a month or so. (2.66 Core 2 Duo / 8 GB RAM)
    – bmike
    Jan 18 '12 at 2:15

Mac OS X Internals: A Systems Approach - Amit Singh - Google Books:

the kernel uses the task and thread abstractions to divide its functionality into various execution flows. The kernel uses a single task—the kernel task—with multiple threads that perform kernel operations such as scheduling, thread reaping, callout management, paging, and Unix exception handling. Thus, xnu is a monolithic kernel containing markedly different components such as Mach, BSD, and the I/O Kit, all running as groups of threads in a single task in the same address space.


The kernel task is not a real task. It represents the kernel, which is the core of the operating system. The bulk of what it does occurs at the direct request of an application. Every time you allocate a large block of memory, open or close a file, read or write a file, pull data over the network, create a new process or thread, etc., your application performs a system call. These calls cause the kernel to do work for your application. Much of that work is billed to the kernel task, but it really is being done by your application, albeit indirectly.


A practical reason why the kernel might be over-working is that your system is out of memory and it is thrashing. Check the memory pressure graph under the Memory tab of Activity Monitor to see if it is yellow or red.

In this case, you can sort processes by Memory and terminate some that consume a lot of it, to reduce the pressure. (e.g. kill some Google Chrome Helper processes)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .