LG Has Been Working On Reduced Boot Times With Hibernation Optimizations

[pal666]

It's more likely they use WebOS https://en.wikipedia.org/wiki/WebOS

well, slides explicitly spell android

[pal666]

That's not quite the same. It suspends to both disk and memory so that in case it loses power can still restore. It doesn't start with sleep and then to hibernation when battery runs low or after a set amount of time.

hybrid suspend is exactly "start with sleep and then to hibernation" "after a set amount of time". i think amount of time is fixed, but that should be easy to change

[carewolf]

hybrid suspend is exactly "start with sleep and then to hibernation" "after a set amount of time". i think amount of time is fixed, but that should be easy to change

You mean in systemd? I read it as if it would only go to hibernation if the battery ran out (it would prepare for it, so hibernation would be the backup in case that happened).

[starshipeleven]

well, slides explicitly spell android

Fair point. I guess it's about time they ditched WebOS and went with what everyone and their dog is using for embedded devices with a GUI (i.e. Android)

[pal666]

You mean in systemd? I read it as if it would only go to hibernation if the battery ran out (it would prepare for it, so hibernation would be the backup in case that happened).

oh, turns out mode which i described is called suspend-then-hibernate. you described hybrid-sleep, systemd supports both

[yturmisil]

I wish somebody would implement a hybrid mode for Linux. But it might require some hardware assist to first bring the computer out of sleep-mode on a certain trigger.

yeah it looks like systemctl suspend-then-hibernate does it

[SystemCrasher]

it won't make slow flash faster

That's debatable statement at best. Look, as concrete example, more powerful CPU with more RAM can afford, say, more powerful compression algo with larger "dictionary" ("backhistory") to look at. Therefore getting better compression ratios, "accelerating" slow flash - by reducing amount of data transferred at read and also keeping more data in RAM cache (so later requests of these pages satisfied at RAM speed). Same for writes: buffered write can "instantly" return and who gives crap how long it would take for kernel to actually flush it out to drive platters, slow flash or something? Well, sometimes we do care. But in many cases we don't.

Furthermore, as RAM size increases, it becomes more and more costly to save it to flash and restore it. Especially slow flash. Well, we HAVE to flush before yanking power, and have to restore whole ram to its state before it going to be operational. Clean booting could imply less RAM use, to begin with. Yes, at cost of loss of state, but I bet we can live with it for stuff like TVs, cameras and other "devices". Not to mention it brings device to clean, well defined and well tested operational state. Something people generally expect from devices like TVs, cameras and so on.

Furthermore, "clean" boot can provide "progressive" feedback, defer un-important initialization and loading, etc. Say, users are unlikely to notice e.g. network interface got up and configured few seconds later, etc. Just because they are rather unlikely to use it that fast. Especially on TV. Furthermore, RAM restore comes with rather unique quirks. Say, apps can be dead sure they established that connection. But it timed out long ago - on other side of link, who tired of waiting for (inactive) system. Sure, eventually some apps would get idea, kernel would eventually face errors, return that to apps, etc. However it still calls for live-looking facade when you actually have quite a zombie. And there are plenty of not so trivial things to sort out. Maybe that's why mentioned approach got only relatively limited use to the date. I'm a bit skeptical about LG being a "game changer" in this regard.

And uhm, if we're about this kind of suspend, the best I know is ... suspend to RAM and ensuring it stays energized. This way it at least avoids need to read RAM content from slow storage - so it could at least enjoy "instant" wakeup, at cost of being volatile and some side-effects. Its also possible to have hybrid approach, both saving state and going RAM, restoring it from storage if power lost, or just wakin up if it isn't case. But it implies at least slow shutdown time since RAM have to be flushed out.

[SystemCrasher]

Guess what? LG is interested in devices with a GUI here.

And so you can see how ppl managed to boot Qt based GUI in shy 0.3 second on boring and dated 1-core omap 3. With like half of that time spent by OMAP and companion power manager IC in their boot ROMs, btw. But uhm I'm dead sure LG is just some mediocre company which likely lacks expertise to do anything comparable. So I woudln't expect to see this level of expertise from them. But I've seen e.g. sony cameras booting similar way real fast. Well, too bad they are overall were still in sony spirit: proprietary junk. So even Linux doesn't brings much advantage if it happens to be Sony

[starshipeleven]

And so you can see how ppl managed to boot Qt based GUI in shy 0.3 second on boring and dated 1-core omap 3.

that's not a full OS with support for apps and stuff, just a basic interface.

But uhm I'm dead sure LG is just some mediocre company which likely lacks expertise to do anything comparable.

Everyone is using Android nowadays