1

[MacBook Pro (13-inch, 2020, Four Thunderbolt 3 ports), 2.3 GHz Quad-Core Intel Core i7, 16 GB RAM, running Monterey 12.6.4]

kernel_task consumes inordinate CPU periodically--around 100+% according to command-line top utility. At the same time all apps using the network lose their connection--e.g. disconnecting Zoom and any other streaming data for 30 seconds to several minutes. As soon as kernel_task drops from the top CPU process, the network resumes. Wi-Fi never drops, just the network traffic stops. This is very disruptive.

I was told that kernel_task does this to cool the CPU because it is overheating. I moved the power connector to one of the right side ports to run cooler (as suggested). It made no difference. Resetting the SMC seems to reduce the number of occurrences, but it eventually happens again in a week or two.

I wrote some scripts to log CPU temperature, fan speed, system load, and when kernel_task takes over. I'm getting CPU temperature and fan speed from running "powermetrics --samplers smc" as root.

I discovered several interesting items:

  1. kernel_task almost never takes over (meaning 100%+ CPU use) when the CPU temperature is high.
  2. kernel_task takes over at normal operating temperatures.
  3. Fan speed doesn't change any differently with kernel_task taking over as if kernel_task doesn't do anything to fan speed.
  4. powermetrics once showed a jump from 69C to 89C over a 5 second span while the fan speed increased by less than 1%. Having a heat-sink on a CPU would make this unlikely.
  5. Laptop is 2 years old but kernel_task was not recognized as a problem until the second year. I don't recall network freezing at all during the first year.

From the above I'm thinking:

  1. We've been lied to about what kernel_task actually does since behavior (consuming 100+% of the CPU) doesn't seem directly correlated with CPU temperature.
  2. kernel_task doesn't directly address overheating.
  3. powermetrics might be lying about temperatures, fan speeds, and when they occur.
  4. SMC is an unreliable mess.
  5. kernel_task unnecessarily throttles/shuts down network activity.

I don't really care about the temperature issues. I want kernel_task to stop blocking my network connection at random times. Is there a fix for any of this besides replacing the hardware?

Improve this question
9
  • 2
    I think there's a lot of inaccuracies in your assertions: what do you consider a high temperature for the CPU? What do you define as a "normal" operating temperature? Why must fan speed by directly correlated to kernel_task? Why does a jump in temperature that's still well within the operating parameters of the CPU, for a short duration necessitate an instantaneous change in fan speed? Why are you equating freezing of an image to be the result of kernel_task affecting networking? There's lots here that appear very disconnected - can you shed some light on them?
    – Allan
    Aug 4 at 15:40
  • 1. I have thousands of data points for operating temperatures. Normal is 65C to about 80C. 88C is running hot. The max is 93C. I've never seen it go over 93C. 2. kernel_task is said to take over and idle processes to bring the CPU temperature down. It would make sense that it would turn up the fan speed, but apparently it does not. 3. A jump of 20C degrees in 5 seconds I've never seen anywhere. I've worked on clustered super computers where we monitor CPU temperature constantly. CPUs don't heat up that fast. It appears to be a data/device/reporting error. [end part 1]
    – Name Withheld
    Aug 4 at 16:47
  • Where did you determine 88C is "running hot" and the max is 93C? The max temp for an i7 CPU for that generation is 100C per Intel. The quantity of your data points isn't in question, but their relation to each other isn't clear.
    – Allan
    Aug 4 at 16:53
  • 4. A jump of 20C in 5 seconds, if continued at that rate would exceed the safe operating temperature within another 5 seconds. If the fan didn't kick in it could be a catastrophic failure. 5. I don't understand what you mean by "freezing of an image". If you mean that why am I connecting kernel_task with my network going off-line, then it's because that's what everyone tells me--plus I'm monitoring the network, CPU, and process list. When kernel_task takes 100% of the CPU, the network goes down. At least I haven't had kernel_task take 500% of the CPU yet.
    – Name Withheld
    Aug 4 at 16:55
  • You cannot extrapolate a temperature increase in a linear fashion as you did. For a CPU to that, you'd need a run away process. Do you have evidence of this? "Freezing image" was a bad term but "freezing out network activity causing Zoom disconnects" is speculation at best. The CPU doesn't handle as much of the network stack as they once did.- that's offloaded onto the Broadcom chips now. I think you're trying to "out think" and "out predict" these systems. Start from a baseline - boot into Safe Mode to rule out 3rd party apps and kexts and see if your issues continue.
    – Allan
    Aug 4 at 17:04

2 Answers 2

Reset to default
3

From the question and your comments, you seem to be very focused on someone (Apple?) "lying" about what kernel_task does. Nothing could be further from the truth. Actually, the source code is freely available.

The main problem with your arguments seem to be that you have come to the misunderstanding that kernel_task's sole purpose is to regulate temperature. That is simply not true.

It is correct that kernel_task plays a role in throttling back a system when there is insufficient cooling. However, that is just a minor part of its operations.

In reality, kernel_task is not an ordinary program running. In this way it is different from all the other processes that you find running on your system. kernel_task instead is a placeholder for operations the operating system kernel performs.

The operating system kernel does some things autonomously, such as playing a part in regulating temperature, but the majority of kernel operations are actually the user space programs (your apps!) that ask it to perform some operation.

And here lies the main reason, why you're stuck solving the main issue. You seem to have the idea that the causality is that kernel_task does something on its own, consumes 100% CPU time, and this then makes your network fall out - so you must stop kernel_task from "doing this thing".

Rather it is most probably the other way around. I.e. your user space programs do "something" or your hardware circumstances are such that network processing can't continue, and as a consequence the kernel ends up "stuck" in a busy loop for longer periods of time.

My advice to you would be to temporarily drop the theory that kernel_task is the culprit and that "temperature" is the cause - and examine other possibilities:

The cause could be in your hardware. Try disconnecting all peripheral devices and try to see if that fixes the issue. If you have access to a similar computer, try duplicating your current software to that Mac and check if that also fails.

The cause could be in your configuration and/or data. Try creating a new user account and log in only with that to see if the problems goes away.

The cause could be in your software (bugs). Try booting in Recovery mode to start up a different version of everything, and see if the problem goes away. You can try upgrading to 12.6.8 or even Ventura to see if that is a fix.

Improve this answer
2
  • I've already stated that it is clear that temperature is not the cause of kernel_task consuming a CPU since this happens when CPU temperatures are very average. Unfortunately the problem happens only after the SMC has been reset 2+ weeks previous. I'm not going to run without displays, an external keyboard and mouse for 2 weeks to see if the problem goes away. I'm fully aware that CPU temperature is not the only thing kernel_task regulates or does. I will eventually upgrade to Ventura once I get IT department approval and have time to deal with it. This appears to be non-fixable.
    – Name Withheld
    Aug 8 at 20:28
  • If it only happens after the SMC has been reset 2 weeks prior - then please stop resetting the SMC. Generally, resetting the SMC is mostly a "placebo drug" that many seem to recommend with no reasonable argument for why that would be involved. You do no need need to run without displays and keyboard and mouse for 2 weeks - just keep these plugged in, and try without the rest of the peripherals if any. From your comment here, is it correct that you're only experiencing the problem for 30 seconds to a minute once every 2 weeks?
    – jksoegaard
    Aug 9 at 8:40
2

Do you happen to use the Cisco AnyConnect VPN client?

You have the exact same symptoms as I have had for months.

And the kernel_task is not the culprit, it's merely a symptom.

The issue, as far as I can understand, is the network filtering that the Cisco AnyConnect client installs. These can be faulty and either hog the system so the kernel struggles or run in the kernel and somehow slow it down.

Either way, I disabled the filters, well I actually removed them, but you can disable them too; go to System Settings > Network > Filters and either disable or remove them.

Here are some links that led me to this conclusion:

Update:

You also need to make sure this is not running:

com.cisco.anyconnect.macos.acsockext

Look at the links I provided here to figure out how to disable it. Honestly, I no longer remember, but it involved a few restarts, as it is loaded on boot.

Improve this answer

You must log in to answer this question.

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