Linux May Be the Best Way to Avoid the AI Nightmare

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:

1. 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.

2. 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.

3. 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

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.