Processor And Memory Optimizations: Tackling System-Slowdown Frustrations
Speaking of storage capacity limitations…but I’m getting ahead of myself. The Nexus One and ThinkPad T60 aren’t the only pieces of hardware that I’ve been struggling with (and learning from) of late. My new-to-me Apple MacBook Air Rev. C is a modest performance uptick from its Rev. A predecessor, both with respect to its CPU clock frequency and its DRAM and HDD burst transfer rates. However, at least until Adobe fixes Flash, it still gets clobbered whenever I try to play a YouTube video or do any other processor-intensive function, for that matter, such as the initial Time Machine full backup that’s in progress as I type these words. The heavily-loaded CPU gets precariously hot, so the kernel_task process fires up and swamps the CPU with NOOP instructions to cool it down…which simultaneously slows every other running process to a crawl.
I broke down the other day and bought another copy of CoolBook, as I’d done with the system’s Rev. A precursor. I’d been reluctant to take this somewhat drastic step, since I had a nagging suspicion that the Apple-unsanctioned hack might have had something to do with my recent-past return-from-sleep problems (although this machine seems stable so far, post-CoolBook install). And even though CoolBook only costs $10, it conceptually bothered me that my existing license wasn’t transferable to the new machine. Nonetheless, it does only cost $10, so I went ahead and took the purchase plunge, with no regrets to date.
The from-factory CPU clock throttle and corresponding core voltage options on the Rev. C MacBook Air were:
- 798 MHz at 0.925V
- 1596 MHz at 1.000V
- 1862 MHz at 1.050V
Using CoolBook, I was able to modify and augment them as follows:
- 798 MHz at 0.925V (the lowest-possible voltage setting)
- 931 MHz at 0.925V
- 1596 MHz at 0.925V
- 1862 MHz at 0.925V
Succussful subsequent burn-in testing using CPUTest assured me of stable system operation. And although you might not think that a scant fraction of a volt reduction in the CPU operating voltage might not make a notable difference in its heat generation, you’d be wrong. I haven’t had a single runaway kernel_task experience since installing CoolBook, in spite of conscious attempts to create such a scenario. Many folks under-volt their CPUs as a means of subsequently over-clocking them while remaining within a particular thermal envelope threshold. My needs are more straightforward; I just want to be able to use the MacBook Air with stock clock speeds in a reasonably robust manner, and CoolBook mostly enables me to accomplish that objective.
I say mostly because the Rev. A-thru-C MacBook Airs are saddled with one other shortcoming which most recently bit me yesterday morning; a system DRAM capacity cap of 2 Gbytes. The system was sluggish, complete with abundant beach balls, even though I could tell from both Activity Monitor and smcFanControl that its CPU was only lightly loaded. From past experience with DRAM-deficient configurations, I had a hunch that excessive virtual memory swaps were the performance-sapping culprit, and a peek at the relevant Activity Monitor page confirmed my suspicion:
At the time that I took this particular screenshot, I happened to have around 150 MBytes of free system RAM, which results in fairly snappy system operation. However, it’s often the case that free memory drops to 10 MBytes or less…at which point another parameter, inactive memory, comes to the forefront. Again, in the above screenshot it’s at around a quarter-GByte. But I frequently see it hovering at around a half-GByte or higher, even when free memory is nearly exhausted.
What’s inactive memory? Apple’s developer documentation defines it as:
Pages that are currently resident in physical memory but have not been accessed recently. These pages contain valid data but may be released from memory at any time.
My beef with OS X centers on the ‘at any time’ portion of the above statement. Apple fanboys’ excuses aside, my observations suggest that even the latest-and-greatest Mac OS 10.6 (aka ‘Snow Leopard’) clings to inactive memory reservations far too tenuously from a just-in-case-I-might-need-the-info-again-in-the-future perspective, thereby forcing the O/S’s memory manager to alternatively leverage orders-of-magnitude slower virtual memory paging to and from the HDD in free-memory-starvation scenarios. I’ve found a slick third-party utility called iFreeMem which forces the O/S to purge inactive memory pages, thereby at least temporarily alleviating the issue. But I remain surprised by OS X’s seeming shortcoming in this regard, both in an absolute sense and relative to Microsoft’s robust Windows 7 competitive approach (which, for example, enables reasonably robust operation even on memory-deficient netbooks).
Memory management isn’t exclusively the domain of conventional computing operating systems, as any of you designing around an embedded O/S already know in intimate detail. As such, I’m reminded of the struggles that Apple customers encountered after updating their iPhone 3Gs to iOS 4.0, parodied in this charming YouTube clip:
- 412 MHz (initially 400 MHz) Samsung 1176JZ(F)-S CPU (ARM11)
- Imagination Technologies PowerVR MBX Lite 3D GPU
- 128 MBytes internal DRAM
to those of the iPhone 3GS as published yesterday:
- 600 MHz Samsung S5PC100 CPU (ARM Cortex-A8)
- Imagination Technologies PowerVR SGX535 GPU
- 256 MBytes internal DRAM
By default, as a result, Apple held back several key iOS v4 features from the iPhone 3G; multitasking, for example, along with graphically rich custom wallpaper backgrounds. Yet, abundant user complaints subsequent to iOS v4 upgrade attempts indicated that Apple hadn’t yet sufficiently neutered the O/S for the iPhone 3G. In response, the company’s made additional tweaks in follow-on iOS v4.1 and v4.2.1, such as by default disabling Spotlight on-the-fly content indexing.
For those of you who’ve jailbroken your handsets, I have another suggestion to offer from personal experience. Remove Winterboard, if you’ve installed it, even if you haven’t yet used it to deviate from the ’stock’ theme. Your iPhone will be notably snappier as a result, with the SpringBoard UI process consuming tangibly less memory than it previously did in its Winterboard-augmented condition. Test it for yourself using the SysInfoPlus or MemTool utilities, if you don’t believe me.