How OS X “Mavericks” works its power-saving magic(arstechnica.com)
arstechnica.com
How OS X “Mavericks” works its power-saving magic
http://arstechnica.com/apple/2013/06/how-os-x-mavericks-works-its-power-saving-magic/
7 comments
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.
That was my first thought too -- Windows has had timer coalescing since at least 2008, if not longer.
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.
It sounds like the OSX version is more of a "forced timer coalescing" feature.
It landed (at least officially) in Windows 7. Quite awhile ago!
> 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?
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?
Honestly, it's probably a flash ad somewhere.
Turning on plugin click-to-activate is good for power, too, not just security.
Turning on plugin click-to-activate is good for power, too, not just security.
I'd sacrifice a lot to have that be the default, just out of charity for everyone elses' benefit.
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.
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.
I forgot to mention. I don't have Flash installed on Safari.
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.
So, the CPU usage of Safari totally depends on what websites you happen to have open.
[deleted]
On my box, Mail.app is currently using about 8% and eclipse is using about 8%.
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?
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?
Who owns the rights to QuarterDeck's old RamDoubler software? I can hear the lawyers coming.
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.
http://www.ambrosiasw.com/ambrosia_times/january_96/3.1HowTo...
http://www.ambrosiasw.com/ambrosia_times/january_96/3.1HowTo...
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.
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.
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)."
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.
> 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.
Apple seems to expect App Nap might create issues, the developer docs for the feature have a note indicating:
> Note: If you experience problems with App Nap, you can temporarily disable it for a particular process by typing:
> defaults write <app domain name> NSAppSleepDisabled -bool YES
> Immediately file a bug describing the app and explaining how to reproduce the problem.
> Note: If you experience problems with App Nap, you can temporarily disable it for a particular process by typing:
> defaults write <app domain name> NSAppSleepDisabled -bool YES
> Immediately file a bug describing the app and explaining how to reproduce the problem.
Apple's note does not imply it's a design issue. Just that the software is not ready and bugs are expected.
> Apple's note does not imply it's a design issue.
At no point did I imply that. I was replying to eddieplan9's declaration that
> Timer Coalescing - is the only one that has the potential to alter application behavior
by noting Apple thinks App Nap may do so.
At no point did I imply that. I was replying to eddieplan9's declaration that
> Timer Coalescing - is the only one that has the potential to alter application behavior
by noting Apple thinks App Nap may do so.
You can also disable the whole thing by typing in
defaults write NSGlobalDomain NSAppSleepDisabled -bool YESI'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.
"Will there be a user method to override/exclude this optimization on processes where this has an undesirable effect?"
The answer to this is in the article: yes.
The answer to this is in the article: yes.
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)?
Only apps with UI will be affected by Power Nap, I believe.
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.
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.
Opps, yep. I knew that! blushes
It's a great idea - is there any word as to whether it's patented/patentable, or might we see this on other OSes?
Timer coalescing has been around for ages. Linux and Windows both already do it. Here's a 2009 article describing it in Windows: https://blogs.technet.com/b/askperf/archive/2009/10/03/windo...
"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.
"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.
Not sure about other features, but for Compressed Memory, there's zRam[1] in Linux that does something similiar if not the same thing.
[1]: http://en.wikipedia.org/wiki/ZRam
[1]: http://en.wikipedia.org/wiki/ZRam
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].
[1] WKdm vs LZO http://terpconnect.umd.edu/~barua/matt-compress-tr.pdf
[2] Gentoo zram http://wiki.gentoo.org/wiki/Zram
[3] Arch zram https://wiki.archlinux.org/index.php/Maximizing_Performance
[4] Debian&Ubuntu zram http://gionn.net/2012/03/11/zram-on-debian-ubuntu-for-memory...
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].
[1] WKdm vs LZO http://terpconnect.umd.edu/~barua/matt-compress-tr.pdf
[2] Gentoo zram http://wiki.gentoo.org/wiki/Zram
[3] Arch zram https://wiki.archlinux.org/index.php/Maximizing_Performance
[4] Debian&Ubuntu zram http://gionn.net/2012/03/11/zram-on-debian-ubuntu-for-memory...
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 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 was going to say that this is crazy: why waste RAM to hold swap space
Because you can get faster performance, and more importantly lower energy usage, on the same hardware.
Because you can get faster performance, and more importantly lower energy usage, on the same hardware.
Also https://github.com/mystilleef/FedoraZram
Note that you need kmod–staging from RPMFusion.
Note that you need kmod–staging from RPMFusion.
FYI there are a couple other implementations of this, with zswap looking like the closest to being merged into mainline linux.
https://lwn.net/Articles/551401/
https://lwn.net/Articles/545244/
https://lwn.net/Articles/551401/
https://lwn.net/Articles/545244/
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.