Sometimes we may find that a system process called kernel_task is consuming many system resources and users try to deal with this problem by directly attacking this process when it is really not the culprit, which is not the solution.
macOS: what is kernel_task, how it works and why it consumes so many resources
Apple has an article in its database and knowledge base that explains how kernel_task works. I will try to explain more broadly why kernel_task is soaring in resource consumption and which are the culprits2 of this problem.
The Apple article states:
One of the functions of the kernel_task process is to help control the temperature of the CPU. In the Activity Monitor, you can indicate that a system process called kernel_task uses a high percentage of the CPU, and during that time you may notice a lot of fan activity. One of the functions of the kernel_task process is to help control the temperature of the CPU. To do this, it will make the CPU less available to the processes that use it intensively. In other words, the kernel_task process responds to the conditions that cause the CPU to get too hot, even if you don’t think the Mac is hot. However, it is not the cause of these conditions. When the CPU temperature drops, kernel_task automatically reduces its activity.
Actually, kernel_task is not the culprit, it’s the solution.
When we have this problem we should not look at this process, but what will be to blame for the process soaring in resource consumption.
Both kernel extensions installed by Apple and kernel extensions that can be installed by other applications have a resource-consuming behaviour that cannot be balanced by Apple when creating the process. Explained to humans, Apple does not prevent the kernel or a kernel extension from fitting a number of specific output resources, i.e. if you develop special drivers, the developer is not required to capture the kernel extension to a limited resource usage of, for example, 50% of the system.
The kernel extension will assume that you can use as many resources as are available to run it. This occurs with both the kernel and all kernel extensions. However, to limit resource usage, Apple uses this process, which is equivalent to a traffic light that limits resource usage to available resources and not more, and the reason for this resource limitation is, as explained in its article, to help control CPU temperature because those processes try to use as many resources as possible. If we look at it from a physical perspective, once we reach a certain limit of available resources in the computer, if a process acts on the processor with one force (action), the system reacts against it with another force of equal value and direction, but in the opposite direction (reaction). 3. That’s why kernel_task consumes so many resources because it’s really trying to stop another process that wants to consume all available computer resources.
Why is this happening?
Now that we know where to look, and it’s not kernel_task, we can get an idea of how to solve these problems. In the end, it’s not about trying to “download” kernel_task but finding the process that is getting it to go off.
The most logical thing would be, in a trial and error environment, to kill the kernel_task process and observe in the Activity Monitor which process is triggered to get a clear idea of where the shots are going but this is not possible because kernel_task belongs to root and as a user4 you cannot kill it, but we are not going to get discouraged by this.
When the kernel_task is triggered because of a process associated with the kernel triggers. These processes can be very varied, but in most cases, it is about:
- A problem with peripherals connected to the Mac: it is common to hear that if you disconnect this peripheral, kernel_task lowers its resource consumption again. We already have an idea of why it goes up: the process associated with that peripheral5 is not really working well because there is a communication problem with that device or because the system kernel or one of its extensions, including any extensions that may have been installed by an application, are causing the problem, including the possibility that two kernel extensions, one from the system and one installed by the drivers of an application, may conflict.
- A software driver problem: for example, access to file systems not directly supported by the system or in general to the use of software standards. For example, if you install software that allows you to view a particular type of video codec that is not directly supported by the system through QuickTime, you may find that the installer has installed a kernel extension to make that video format available to all applications so that it looks like the video codec is clearly supported across all applications in the system.
In general, this problem is usually caused by:
- Drivers for peripherals that we installed at the time and that were left behind when we stopped using that device.
- An updated software driver that come into direct conflict with the system.
- The device itself that does not support a standard correctly6 or the cables associated with it. The cable thing is important: a bad cable can ruin your day.
How to resolve the issue of kernel_task?
In many cases, kernel_task problems are associated with I/O Kit. I/O Kit is a collection of system frameworks, libraries, tools and other resources for creating device drivers for OS X and macOS. It is based on an object-oriented programming model implemented in a restricted form of C++ that omits features unsuitable for use within a multithreaded kernel. By modelling the hardware connected to an OS X/macOS system and abstracting common functions for devices in certain categories, the i/O Kit streamlines the process of developing drivers for an Apple device. Even if you are not a developer, it is interesting to take a look at the I/O Kit documentation to understand how it works and what it does.
It is also possible that the problem with the kernel and its extensions is due to the cache. When macOS boots, it saves a cache of available kernel extensions so that you can boot faster next time. If that cache has problems, it is possible that kernel_task will trip. To rebuild the kernel cache in macOS Sierra and macOS 10.13 High Sierra:
- Open the Terminal
- Enter the command
sudo kextcache -i /
- You will be asked for the administrator password
- Once the process is finished, restart the Mac. It will take some time to restart since you have to rebuild that cache again.
Observe the behaviour of kernel_task. If everything has returned to normal, you know that the problem was the cache.
Related posts:
Mac computers with Apple M1 “Crashes” in MacOS Recovery
Leave a Reply