kernel_task Is Protective, not Problematic

(Adam Engst) #1

Originally published at:

Who knew? Howard Oakley reveals an Apple support note that explains that the kernel_task process monopolizes your Mac’s CPU to protect it from overheating and isn’t itself causing the problem.

(Jeff Porten) #2

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.

(Al Varnell) #3

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

(frederico) #4

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’.

(James Reynolds) #5

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…

(Adam Engst) #6

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.

(James Reynolds) #7

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.

(Greg Scarich) #8

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.

(Adam Engst) #9

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.

(Jeff Porten) #10

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.