I'm surprised OS X didn't already using Timer Coalescing or lower process priority of unfocused applications. The Linux kernel has used Timer Coalescing for a long time. On Windows, there are utilities like Process Lasso that enables user-configurable process priority adjustments.
The whitepaper at http://msdn.microsoft.com/en-us/library/windows/hardware/gg4... indicates that Windows timer coalescing requires an application to explicitly opt in. The article describes OS X Mavericks' support as applying to all upcoming timers while on battery power (presumably excluding particular classes of timing-sensitive applications, such as audio playback), which would be a much more aggressive approach than in Windows.
Yea that's fair. I was actually thinking of timer coalescing on the server OS for improved power efficiency/performance -- I'm sure IIS, MSSQL, etc. all opt-in to coalescing responsibly.
It sounds like the OSX version is more of a "forced timer coalescing" feature.
Well, nobody (i believe) said that with Mavericks you would. The new MBAir with crazy 12h batteries are running Mountain Lion. It's just because Haswell.
> One of our Mac-using editors notes that the current version of Safari consumes about 15 percent of CPU resources when running in the background, so these power losses can be significant.
Seriously? I can't say I've had an app use more than 3-5% of my CPU while it was sitting idle. I don't think it has anything with my OS. Is this what others are experiencing?
Because the usage is percentage based, of course it depends entirely on which CPU you currently have. I imagine 3-5% of the latest Macbook Pro Retina i7, isn't the same as the 2010 Macbook Air's Core 2 Duo.
It's happening here on my Mac. It goes from 12% to 30% even when the application is hidden. I'm running the latest Safari with three windows and seven open tabs on average.
Safari 6 has been a major resource hog. But I can't stand that ugliness of Chrome. Solution while the next iteration doesn't solve this: close tabs or add ram.
As another commenter suggested, I suspect ClickToFlash or something similar would help. For comparison, on the same version of Safari, I have more than 50 tabs open in several windows and Safari uses about 3% CPU in the background.
Badly written websites or plugins can easily cause that to increase. On my rMPB at the moment, Firefox is in the background and using 10-12% CPU. Chrome has Silverlight running for some reason (probably from when I used Netflix earlier), and that is using 8-10% CPU.
Safari itself does not magically eat your CPU but websites running badly written javascript do. (Not to mention the infamous plugin thingy from Adobe, which any sane person will disable anyway.)
So, the CPU usage of Safari totally depends on what websites you happen to have open.
On my PowerPC based PowerBook 14" background apps like Mail would consume 2-4% CPU quite often. Now on my Mac Mini with an i7 processor, it's about the same percentage!
2% of a contemporary processor it alot more than 2% of a 10 year old one.
So is Mail now doing alot more in the backgound than before? Or is this some artifact in the way CPU utilitation is measured?
I remember Connectix RAM Doubler, trying it and feeling how painfully it slowed down OS 8. I believe it used virtual memory, (it had that goofy little slider that let you "double" your ram) . I doubt it compression. Man, I almost forgot about RAMDoubler
I'm also filled with nostalgia ;). According to this post on the Ambrosia SW page (more nostalgia!), Ram Doubler used both VM and compression. The piece is light on technical details but fills in a bit more of the picture.
Actually, I was thinking of a Windows program named 'MagnaRAM' that Quarterdeck sold.
MagnaRAM worked by replacing a portion of Windows' virtual memory system. MagnaRAM would insert itself in the string of Windows Programs that determined what pieces of RAM will be moved to the hard disk. Instead of writing directly to the hard disk, the information to be written would go to MagnaRAM's own buffer as this was a faster process. During CPU idle, MagnaRAM would compress the information in its own RAM buffer. When the RAM buffer becomes full, it is then swapped to the hard disk taking both less time and less space
Sounds very similar to zram on Linux. Virtual memory always seemed like a black art to me.
I suspect that this technology works by optimizing the kernel process scheduler by using some heuristics to determine what should be put to the background (e.g determining what sort of syscalls are made, etc).
Will this technology be intelligent enough to know a network server process (e.g socket syscalls)? Will there be a user method to override/exclude this optimization on processes where this has an undesirable effect?
I think another good idea for OS developers is to push the concept of fibers more over threads. Often a multi-threaded application can be re-patterned to use fibers for immediate CPU optimization.
It sounds like a great OS improvement, especially coupled with SSDs. But I'm hoping we can turn the magic off for certain processes when the magic gets too crazy.
"App Nap can be automatically triggered if an app’s windows are not visible and the app is not playing audio..." When they say foreground and background they're taking about the GUI.
BTW, "developers can explicitly make an app ineligible for App Nap by using the existing IOKit IOPMAssertion API (used today in OS X to prevent the system from sleeping while an app is busy)."
The developer documentation goes into more details:
> App Nap reduces power consumption by completely suspending your app’s execution when it meets certain criteria. This ensures that your app does not periodically wake up to do unnecessary work. An app is considered to be a candidate for sleep if:
> * It is not visible—if all of an app’s windows are either hidden by other windows or minimized in a hidden dock, and the app is not in the foreground
> * It is not audible
> * It has not explicitly disabled automatic termination
> * It has not taken any power management assertions
> When all of these conditions are met, OS X may put the app to sleep. While asleep, the app is placed on a scheduling queue that rarely gets actual time on the CPU.
There are also new methods provided on NSProcessInfo to temporarily prevent sleep and increase scheduler timer precision.
The article talks about three technologies, and IMHO none is about putting processes to background. The first one is about compressing pages instead of swapping them to secondary storage. This should be a net gain in almost all scenarios. The second - App Nap - only applies to GUI applications, and there are opt-out controls. The third - Timer Coalescing - is the only one that has the potential to alter application behavior, and it only kicks in when the machines runs on battery.
I'm really hoping there's a GUI way for the average user to disable it. Otherwise, writing to plist is not something easily done by the average user. Some apps aren't readily updated. Another thing Apple might do is publish a list of App Names and version/build number metadata to automatically disable it for apps known to have problems with AppNap.
Does a process that's running intensively (say, a python script in the shell) still be limited, or does this only apply to NSWindows (or something similar)?
Pedantic correction: App Nap is the feature being discussed here to give less CPU time to apps which don't need it.
Power Nap is the marketing name of the previously-released (in 10.8) feature whereby a Mac in sleep mode still does things like check email, update calendars, perform automatic photo downloads, etc.
"App Nap" is a familiar concept to anyone who has ever played a game with unfocused framerate caps (like most MMOs, for example). It being enforced by the OS may be new, though. It kind of feels like a more aggressive `nice` though.
zram in Linux kernel should be quite close to what the advertised "Compressed Memory" feature is in Mavericks.
AFAIK zram is using LZO compression. According to some tests it is about the same efficiency as WKdm (used in Mavericks) but it has bit slower compression speed [1].
zram is an experimental kernel module since 3.2 and can be installed: [2], [3], [4].
Ok so zram creates a compressed block device in memory. Apparently it's sometimes used to hold a swap space for virtual memory. Compression rates are about 50%, ie you can roughly "double" your memory.
I was going to say that this is crazy: why waste RAM to hold swap space, when you could use that RAM to avoid swapping in the first place. I still think it'd be odd to reserve a significant chunk of your memory for it. But I can see how it'd be pretty cool if you can manage it dynamically, ie. only start compressing memory as you run out of it to avoid hitting the disk.
Of course the usual rule still applies: if your PC swaps often, get more RAM; or if the RAM is not upgradable, go back in time and buy a machine with more RAM, then smack yourself on the head for not doing so in the first place. :)
I wonder if they are doing anything to further reduce SSD usage in the OS that will help. Many of the tips people use to reduce wear and tear on their SSDs (noatime, journaling, sleep image, etc.) seemingly would have further benefit to saving on power.
Current consumer SSDs even with developer / power user usage patterns should be able to run for at least 30 years before the flash is no longer guaranteed to work (1000 block wipes). The write amplification problem was mostly for the first naive SSD implementations that would do a block wipe cycle on every write. These naive SSDs have about 4 IOPS of 4K random write, you'll notice that.
When I disable noatime I am not doing it to conserve write cycles, I'm doing it to reduce I/O. Less electrical impulses running across my bus, the better.
