acodega · June 21, 2017 05:59
diff --git a/kernel_task high CPU memory b/kernel_task high CPU memory
 There's a way you can see what the naughty kernel_task is up to.

 /Applications/Utilities/Activity Monitor.app
 View -> All Processes
 Select the `kernel_task` process in the list
 <gear menu> Spindump

 So if it says something like `45 samples (187-231)` you know that bit was short lived - but if it says `1000 samples (1-1000)` - either it was blocked during the 10 second run, or it might be a culprit chewing away at your machine

 Long number of samples + high `cpu time` value for the thread = indicator it put a lot of load on your machine

 And then in the traceback for kernel_thread, you'll see memory addresses in square brackets next to the steps `[0xff... ]` And at the end of a thread you'll see any kernel extensions that were loaded into the application memory space for that thread. And they'll mark out what memory ranges each kernel extension was loaded into. So you can see <this bit of memory> is in <this range> = that kernel extension is messing with you. Which is mostly what you'll see, for kernel_thread, since it serves as a host process for the extensions in addition to the kernel itself.
	There's a way you can see what the naughty kernel_task is up to.

	/Applications/Utilities/Activity Monitor.app
	View -> All Processes
	Select the `kernel_task` process in the list
	<gear menu> Spindump

	So if it says something like `45 samples (187-231)` you know that bit was short lived - but if it says `1000 samples (1-1000)` - either it was blocked during the 10 second run, or it might be a culprit chewing away at your machine

	Long number of samples + high `cpu time` value for the thread = indicator it put a lot of load on your machine

	And then in the traceback for kernel_thread, you'll see memory addresses in square brackets next to the steps `[0xff... ]` And at the end of a thread you'll see any kernel extensions that were loaded into the application memory space for that thread. And they'll mark out what memory ranges each kernel extension was loaded into. So you can see <this bit of memory> is in <this range> = that kernel extension is messing with you. Which is mostly what you'll see, for kernel_thread, since it serves as a host process for the extensions in addition to the kernel itself.