I know this was a long time ago but this fixed the problem for me
http://www.rdoxenham.com/?p=259
---------
Posted on June 5, 2012
I use a wide variety of operating systems at home, all services are provided by Linux, e.g. firewall, routing, file-storage and DLNA media. However, I like using a Mac too, I have a late-2009 MacBook Air which I use whilst travelling. Despite all of Lion’s flaws, I really like using it- full-screen apps, gestures and the new Mail.app is really impressive. The specification of this machine really isn’t anything special, the lack of expansion really leaves a lot to be desired but for what I do- it’s plenty. I will certainly be upgrading to the new Ivy Bridge MacBook Air when it comes out, perhaps then I’ll have more than 2GB memory and can run VM’s too(!).
The biggest problem I’ve been having with this machine on Lion (didn’t have it on Snow Leopard) is to do with kernel_task. Instead of splitting all of the underlying kernel operations into their own individual processes (and associated threads) they are all consumed by a single ‘task’ (more of a representation of the underpinnings of the microkernel architecture) that appears in the process list. What I’ve been noticing is that this ‘task’ sometimes goes out of control, consumes CPU resources with the utmost priority. For a long time I wasn’t sure what it was doing, it seemed to be kicking in when I was doing something that was relatively intensive (for a Mac anyway), e.g. YouTube.
A lot of people suggested that ‘rogue kexts’ (kernel drivers/modules) could be causing the problem, perhaps an incompatible module was being started by OS X that was installed when the system was running Snow Leopard. This seemed to make sense as a boot in safe-mode would cause no problems. Suffice to say, I created a Lion Install-USB and re-installed from scratch; guess what… same problem within hours! After a bit of digging around and investigating the kernel_task ‘process’ it was clear to see that it was looping through something continually. After further research I discovered that the kernel will keep looping some very simple tasks, e.g. getting the date, therefore ‘consuming’ (with the highest priority) the majority of the CPU in a bid to cool the system down.
So, it’s all to do with temperature control- you ‘remove’ a large portion of the CPU share from other applications and carry out low-overhead tasks continually until the CPU temperature drops. This sounds like a great solution to cooling, but it’s very intrusive. It’s agressive nature drags the system to a halt in a lot of ways, despite the fact that the CPU in my MacBook Air rarely exceeds 70 degrees (centigrade). Considering the TJ Max of my little 2.13GHz Core2Duo is 85 degrees I’d rather kernel_task not take this invasive action.
Thankfully, this “feature” is built into a kext, in which each model identifier specifies how to control the temperature of the CPU via this invasive action. The simple fix is to remove the entry for your model identifier from this kext- if it “doesn’t know” what to do with your particular model, it won’t take any action. Now, here comes the disclaimer… by taking the same action as I will outline below, I take absolutely no responsibility for any damage or loss caused to you or your property, you do this of your own free will. You’re over-ruling functionality that was designed to prolong the life of your equipment, despite the fact that it’s invasive and very annoying it’s there for a reason. Anyway, on to the fun stuff…
Firstly, you’re going to need the model identifier of your pesky Mac:
$ system_profiler -detailLevel mini | grep "Model Identifier:"
Model Identifier: MacBookAir2,1
|
The kext we need to modify is IOPlatformPluginFamily.kext, you can verify it is running by-
sh-3.2# kextstat | grep IOPlatformPluginFamily
67 3 0xffffff7f81229000 0x7000 0x7000 com.apple.driver.IOPlatformPluginFamily (5.1.0d17) <8 7 6 5 4 3>
|
Within this kext will be another further kext- ACPI_SMC_PlatformPlugin.kext, in which each recent Macintosh model is listed with relevant instructions that the kernel uses to determine how and when to invoke the control. (Make sure you switch to root now)
sh-3.2# cd /System/Library/Extensions/IOPlatformPluginFamily.kext/
sh-3.2# cd Contents/PlugIns/ACPI_SMC_PlatformPlugin.kext/
sh-3.2# cd Contents/Resources/
sh-3.2# ls | wc -l
49
|
So, there’s 49 different profiles listed in this kext as of the writing of this. We simply need to move the ‘plist’ file for the model identifier we discovered earlier out of that directory, so in my case I need to move file ‘MacBookAir2_1.plist’ out of this directory (to somewhere safe), but replace my model identifier with your specific one.
sh-3.2# mv MacBookAir2_1.plist /Users/<your username>/
|
You can simply reboot now for the changes to take effect. We could have removed the entire kext but it’s much safer to remove the plist file for the specific model as (to be honest) I don’t know what the rest of that kernel module does. I’ve been using this ‘fix’ for a few days now and not noticed any problems at all- overall it’s much quicker and I don’t have to worry about it running out of steam. What I would recommend is that you be a bit more careful about the placement of your Mac, you don’t want to be covering the exhaust. The Mac should protect itself if it *does* reach max temperature but I would just be a little more careful.
Note: It’s likely that this kext will get updated in the future by Apple in their update packs and as a result will replace the file you deleted/moved therefore you may have to repeat this process in the future 
Let me know how you get on.
