Microsoft has Copilot Plus PCs loaded with AI, and rumors are that Apple is all in on AI, too, but if you don't want AI in everything you do, there is another option: Linux.
Do you remember when you could put your Mac to sleep, and when you woke it up a few days later, the battery would barely have dropped? Not now, because your computer never really sleeps anymore.
I assume that the Mac has some kind of hibernation function, and that that will reduce the battery drop to effectively zero.
Waking from hibernation is sooo much slower than waking from sleep. Apple silicon macs are very efficient in their S0 standby so they’ll go days before entering hibernation. Kinda odd that they bring that up now that Apple has fully transitioned to ARM machines where this isn’t really an issue. That said S0 standby on this 2019 Macbook I have for work is dogshit.
I have my Linux Thinkpad set up to just go directly to hibernation. If I flip the lid open, by the time I’ve closed up my laptop backpack, stashed it, pulled my seat out, sat down, and scootched up, it’s pretty much up. And if it’s hibernated, then you don’t wind up with a case where you leave it in your bag for a long time, it draws down a bunch of a battery, and next time you open the thing up, maybe away from a plug, you don’t have a big chunk of your battery slorped up.
does some timing
Booting up and responding after a hibernation is a little under 30 seconds.
Doing so after an S3 sleep is a little under 5 seconds.
Now, okay, that’s just the system being back up, and it’s gonna have to broadcast a query, wait for responses from WAPs, associate with a wireless access point and get a DHCP lease before the network’s up, so maybe there’s a little extra time until the thing is fully usable, but still.
I guess…hmm. I guess I can see doing a sleep-with-delayed hibernation for something like the case where someone’s moving between an office and a conference room. Like, wait 5 or 10 minutes, and if it’s still sleeping, then hibernate. What are the defaults?
goes looking
Hmm. Okay, so looks like on Debian, the default is to sleep (suspend) until the battery is down to 5%, then do a hibernate if it hits that critical level. Yeah, I never want to wait that long.
Aight, I’m gonna move from directly hibernating to a 5 minute sleep or 5% battery, whichever first, then hibernate. I guess that’s maybe a good tradeoff for a scenario where a laptop is being frequently closed and opened, but it still shouldn’t result in much extra power consumption.
The Intel MacBook waking up from hibernation is about 30 seconds to get to the login prompt, 30 seconds for the login prompt to actually work, then 10-15 seconds after entering the password to get to a usable desktop environment with the wifi generally connecting within that window. It’s now awful, but traditional S1-3 standby was so much better. S0 standby is great if you’re frequently opening and closing the device, but is unusable on higher power devices.
But that’s with only 8 gigs of ram on this MacBook, the more ram the longer it takes. The 32 gigs of ram in my actual work laptop (ThinkPad P1 11th gen i9) takes about a minute to wake from hibernation, and like 2 minutes for it to fully get situated. If I do that on battery that’s about 3-5% of my battery just waking from hibernation.
The Intel MacBook waking up from hibernation is about 30 seconds to get to the login prompt, 30 seconds for the login prompt to actually work, then 10-15 seconds after entering the password to get to a usable desktop environment with the wifi generally connecting within that window.
Hmm. Yeah, okay, I can see about a minute-and-a-half being obnoxious.
So, the login prompt can probably be dealt with by just having some way to treat the login process specially and paging it in sooner. Like, I can’t believe that it uses all that much memory. If it isn’t an isolated process, make it one.
But that’s with only 8 gigs of ram on this MacBook, the more ram the longer it takes. The 32 gigs of ram in my actual work laptop (ThinkPad P1 11th gen i9) takes about a minute to wake from hibernation, and like 2 minutes for it to fully get situated.
I’m using a 32 gig laptop. But most of that doesn’t get used other than as disk cache, and I believe that normally, Linux isn’t gonna restore the disk cache; it’ll just drop the cache contents. Right now, I’m using 2.3G for actual application usage.
considers
I figure that maybe the desktop shell or whatever Apple calls it these days – going back to classic MacOS, the Finder – probably is more-heavyweight than what I’m using, but I figure that they could maybe do something like temporarily twiddle I/O priority on processes during the de-hibernation process. Like, okay, anything other than the foreground process gets an I/O priority penalty for a period of time. Like, maybe your music player or something is choppy for a few seconds, but whatever you’re directly interacting with should be active more-quickly.
If this is SSD, that seems kinda long, still. Like, it shouldn’t take 2 minutes to move 32GB to SSD.
It looks like I get about 3GBps reading from SSD:
$ dd bs=100M iflag=direct if='setup_act_of_war_direct_action_1.06.3_(24183)-1.bin' of=/dev/null
40+1 records in
40+1 records out
4294098942 bytes (4.3 GB, 4.0 GiB) copied, 1.28615 s, 3.3 GB/s
$
And that’s doing I/O going through the filesystem layer; I dunno if Macs use a swap file or swap partition these days, but if they have a dedicated partition, they might pull a bit more throughput). So if you figure that in terms of raw I/O performance, it shouldn’t take more than about 10 seconds to fully restore memory contents on a 32GB laptop with comparable SSD performance, even if the OS has to fully-restore the entire contents of the memory. There’s some hardware state restoration that has to happen prior to starting to pull stuff back into memory, but for the memory restoration, that’s the floor. If it’s more than that, then presumably it’s possible to optimize by reprioritizing reads.
So, I guess that there are maybe a couple areas for potential improvement:
If the thing is locked and requires a password or something, you know that the user is gonna have to use the login process before anything else. Get that paged back in as soon as possible. Ditto for the graphics layer, Quartz or whatever Apple has these days. Strip that login process down; maybe separate it from whatever is showing blingy stuff on the login screen. Can have the OS treat it specially so that it’s first in line to come up.
The next goal is to get the stuff that the user needs to be immediately interacting with back into memory. My guess is that that’s probably the launcher and/or task switcher and the foreground process. Might have a limited amount that can be done to strip the launcher/task switcher down. Have all processes other than those few favored processes get a temporary I/O priority penalty.
One wants to keep the I/O system saturated until the system is to a fully-restored state, so that we don’t have to have the latency of waiting for a process to request something to bring it back into memory. So have some process that gets started, runs with I/O priority below all other processes, and just does bulk reads of valid pages from the pagefile (or wherever MacOS stores the hibernation state). Once that thing has completed, the system should be fully-warmed back to pre-hibernation state. That eliminates idle gaps when maybe there’s no reads happening. Maybe restore the disk cache state after that, if that doesn’t happen now, if the reason the system is sluggish is because it’s having to re-warm the cache bit by bit. On my Linux box, it looks like post-restoration, the disk cache is empty, so it’s probably just dropping the disk cache contents (which probably speeds up hibernation, but is gonna mean that the post-hibernation system is gonna have to figure out what it’s sensible to cache).
EDIT: Also, relevant Steve Jobs quote that comes to mind:
Larry Kenyon was the engineer working on the disk driver and file system. Steve came into his cubicle and started to exhort him. “The Macintosh boots too slowly. You’ve got to make it faster!”
Larry started to explain about some of the places where he thought that he could improve things, but Steve wasn’t interested. He continued, “You know, I’ve been thinking about it. How many people are going to be using the Macintosh? A million? No, more than that. In a few years, I bet five million people will be booting up their Macintoshes at least once a day.”
“Well, let’s say you can shave 10 seconds off of the boot time. Multiply that by five million users and thats 50 million seconds, every single day. Over a year, that’s probably dozens of lifetimes. So if you make it boot ten seconds faster, you’ve saved a dozen lives. That’s really worth it, don’t you think?”
We were pretty motivated to make the software go as fast as we could anyway, so I’m not sure if this pitch had much effect, but we thought it was pretty humorous, and we did manage to shave more than ten seconds off the boot time over the next couple of months.
I assume that the Mac has some kind of hibernation function, and that that will reduce the battery drop to effectively zero.
Waking from hibernation is sooo much slower than waking from sleep. Apple silicon macs are very efficient in their S0 standby so they’ll go days before entering hibernation. Kinda odd that they bring that up now that Apple has fully transitioned to ARM machines where this isn’t really an issue. That said S0 standby on this 2019 Macbook I have for work is dogshit.
How seriously painful is that boot time?
I have my Linux Thinkpad set up to just go directly to hibernation. If I flip the lid open, by the time I’ve closed up my laptop backpack, stashed it, pulled my seat out, sat down, and scootched up, it’s pretty much up. And if it’s hibernated, then you don’t wind up with a case where you leave it in your bag for a long time, it draws down a bunch of a battery, and next time you open the thing up, maybe away from a plug, you don’t have a big chunk of your battery slorped up.
does some timing
Booting up and responding after a hibernation is a little under 30 seconds.
Doing so after an S3 sleep is a little under 5 seconds.
Now, okay, that’s just the system being back up, and it’s gonna have to broadcast a query, wait for responses from WAPs, associate with a wireless access point and get a DHCP lease before the network’s up, so maybe there’s a little extra time until the thing is fully usable, but still.
I guess…hmm. I guess I can see doing a sleep-with-delayed hibernation for something like the case where someone’s moving between an office and a conference room. Like, wait 5 or 10 minutes, and if it’s still sleeping, then hibernate. What are the defaults?
goes looking
Hmm. Okay, so looks like on Debian, the default is to sleep (suspend) until the battery is down to 5%, then do a hibernate if it hits that critical level. Yeah, I never want to wait that long.
Aight, I’m gonna move from directly hibernating to a 5 minute sleep or 5% battery, whichever first, then hibernate. I guess that’s maybe a good tradeoff for a scenario where a laptop is being frequently closed and opened, but it still shouldn’t result in much extra power consumption.
The Intel MacBook waking up from hibernation is about 30 seconds to get to the login prompt, 30 seconds for the login prompt to actually work, then 10-15 seconds after entering the password to get to a usable desktop environment with the wifi generally connecting within that window. It’s now awful, but traditional S1-3 standby was so much better. S0 standby is great if you’re frequently opening and closing the device, but is unusable on higher power devices.
But that’s with only 8 gigs of ram on this MacBook, the more ram the longer it takes. The 32 gigs of ram in my actual work laptop (ThinkPad P1 11th gen i9) takes about a minute to wake from hibernation, and like 2 minutes for it to fully get situated. If I do that on battery that’s about 3-5% of my battery just waking from hibernation.
Hmm. Yeah, okay, I can see about a minute-and-a-half being obnoxious.
So, the login prompt can probably be dealt with by just having some way to treat the login process specially and paging it in sooner. Like, I can’t believe that it uses all that much memory. If it isn’t an isolated process, make it one.
I’m using a 32 gig laptop. But most of that doesn’t get used other than as disk cache, and I believe that normally, Linux isn’t gonna restore the disk cache; it’ll just drop the cache contents. Right now, I’m using 2.3G for actual application usage.
considers
I figure that maybe the desktop shell or whatever Apple calls it these days – going back to classic MacOS, the Finder – probably is more-heavyweight than what I’m using, but I figure that they could maybe do something like temporarily twiddle I/O priority on processes during the de-hibernation process. Like, okay, anything other than the foreground process gets an I/O priority penalty for a period of time. Like, maybe your music player or something is choppy for a few seconds, but whatever you’re directly interacting with should be active more-quickly.
If this is SSD, that seems kinda long, still. Like, it shouldn’t take 2 minutes to move 32GB to SSD.
It looks like I get about 3GBps reading from SSD:
And that’s doing I/O going through the filesystem layer; I dunno if Macs use a swap file or swap partition these days, but if they have a dedicated partition, they might pull a bit more throughput). So if you figure that in terms of raw I/O performance, it shouldn’t take more than about 10 seconds to fully restore memory contents on a 32GB laptop with comparable SSD performance, even if the OS has to fully-restore the entire contents of the memory. There’s some hardware state restoration that has to happen prior to starting to pull stuff back into memory, but for the memory restoration, that’s the floor. If it’s more than that, then presumably it’s possible to optimize by reprioritizing reads.
So, I guess that there are maybe a couple areas for potential improvement:
If the thing is locked and requires a password or something, you know that the user is gonna have to use the login process before anything else. Get that paged back in as soon as possible. Ditto for the graphics layer, Quartz or whatever Apple has these days. Strip that login process down; maybe separate it from whatever is showing blingy stuff on the login screen. Can have the OS treat it specially so that it’s first in line to come up.
The next goal is to get the stuff that the user needs to be immediately interacting with back into memory. My guess is that that’s probably the launcher and/or task switcher and the foreground process. Might have a limited amount that can be done to strip the launcher/task switcher down. Have all processes other than those few favored processes get a temporary I/O priority penalty.
One wants to keep the I/O system saturated until the system is to a fully-restored state, so that we don’t have to have the latency of waiting for a process to request something to bring it back into memory. So have some process that gets started, runs with I/O priority below all other processes, and just does bulk reads of valid pages from the pagefile (or wherever MacOS stores the hibernation state). Once that thing has completed, the system should be fully-warmed back to pre-hibernation state. That eliminates idle gaps when maybe there’s no reads happening. Maybe restore the disk cache state after that, if that doesn’t happen now, if the reason the system is sluggish is because it’s having to re-warm the cache bit by bit. On my Linux box, it looks like post-restoration, the disk cache is empty, so it’s probably just dropping the disk cache contents (which probably speeds up hibernation, but is gonna mean that the post-hibernation system is gonna have to figure out what it’s sensible to cache).
EDIT: Also, relevant Steve Jobs quote that comes to mind:
https://www.folklore.org/Saving_Lives.html
Apple Silicon machines are also much quicker to wake up from hibernation