Skip to content
Thoughtful, detailed coverage of everything Apple for 29 years
and the TidBITS Content Network for Apple professionals
Photo of a firefighter battling a blaze

Photo by skeeze


kernel_task Is Protective, not Problematic

Thanks to Howard Oakley for explaining something that has bothered me for years. When my iMac is struggling under a heavy CPU load, performance suffers, and I can hear its fans ramping up. Checking in Activity Monitor often reveals that a process called kernel_task is taking a large percentage of the CPU. I mutter something unprintable and hope that things resolve themselves soon, which they usually do, eventually. What the %$#*@^ could kernel_task be doing?

It turns out that kernel_task is actually stepping in to make the CPU less accessible to other processes that are taxing the CPU so intensely that they’re causing its temperature to reach dangerous levels. In other words, kernel_task is protecting your CPU from overheating, and not itself causing the problem. Once the CPU temperature drops, kernel_task automatically backs off so other processes can resume their activity.

Read original article

Subscribe today so you don’t miss any TidBITS articles!

Every week you’ll get tech tips, in-depth reviews, and insightful news analysis for discerning Apple users. For 28 years, we’ve published professional, member-supported tech journalism that makes you smarter.

Registration confirmation will be emailed to you.

Comments About kernel_task Is Protective, not Problematic

Notable Replies

  1. This is the most jaw-droppingly useful information I’ve read in a year. I’ve been trying to troubleshoot this for months—I thought I had rogue background processes in my kernel.

  2. I have known that for a long time now. Sorry haven’t shared, but I never noticed it coming up here.

  3. Of course, Apple could try not being obscure, and instead of kernel_task, which sounds like “hi, system here, I’ve got housekeeping to do, even though you’re desperate for every cycle you can grab right now, I’m going to tidy up right now; you can have your system back whenever I’m done.”; as opposed to, say, ‘CPU_overheat_protection’. If, indeed, that is its only purpose, its just another example of engineers living in another world. They may as well call it ‘goad_user’.

  4. My understanding is that kernel_task was the system doing things, specifically it was “top” or Activity Monitor’s way of showing system calls like file and networking activities. User level applications do not have permission to hardware and other kernel tasks so what kernel_task represents is the system API’s that bridge between user level stuff and stuff that requires kernel level permissions.

    I heard this at a WWDC years ago and the presenter was basically saying that kernel debugging was extremely difficult because it’s so hard to see what the kernel is actually doing. Dtrace was suppose to help with this. It’s been a long time since I’ve been to WWDC so I don’t know what the current status is but kernel_task is still there so…

  5. That was always what I thought too, but Apple is very clear in that support note about how at least some of kernel_task’s function is to protect against CPU overheating.

  6. My guess is what they really mean is that a process is calling system API’s aggressively and kernel_task throttles itself instead of doing things as quickly as it’s being asked. It seems like bad design to have kernel_task ramp up it’s usage so that the cpu scheduling favors kernel_task instead of other processes. In fact, nice already can slow down greedy processes. I really think Apple means that the kernel_task is just throttling how fast it performs system API’s. I don’t know much about kernels so I could be wrong though.

  7. Maybe my understanding of physics is off, but if kernel_task is using more CPU than any other task, how is that reducing energy use (protecting from overheating)?

    Agree that better naming of the process would be helpful.

  8. All I can assume is that kernel_task, by virtue of being Apple’s own low-level code, can block other processes from using the CPU without itself using the kind of behavior that causes overheating.

  9. To be clear, kernel_task is the bootstrap and is always doing useful things; IIRC, it’s always PID 1 and has a nice value of -10, so it pre-empts all other usage. Ramping up its apparent usage is an elegant way of telling the rest of the system to fight over a smaller portion of CPU pie. In theory, if it claimed 400% on a four-core system, everything else would beachball.

Join the discussion in the TidBITS Discourse forum