LG Has Been Working On Reduced Boot Times With Hibernation Optimizations

[phoronix]

Phoronix: LG Has Been Working On Reduced Boot Times With Hibernation Optimizations

LG Electronics has been exploring improvements around hibernation/suspend-to-disk to speed-up the Linux boot process for consumer electronics rather than performing cold boots and as part of that is working towards upstream optimizations...

http://www.phoronix.com/scan.php?pag...Hibernate-Boot

[cybertraveler]

Personally, if I need to power off a system, I like to always take the opportunity to do a full shutdown. I prefer doing this over hibernating as it means any memory leaks will be reset and any applications that have entered a non-intended erroneous state will be reset to an intentional and stable state. I know that neither of those two things should happen, but they sometimes do.

[andrei_me]

This probably applies to their SmartTVs, I have one from LG, in the setting you can choose the behavior when you turn-off, one of them seems like the hibernation described in the PDF instead of the full shutdown that takes longer to turn on later

[skeevy420]

This probably applies to their SmartTVs, I have one from LG, in the setting you can choose the behavior when you turn-off, one of them seems like the hibernation described in the PDF instead of the full shutdown that takes longer to turn on later

My TV has a hybrid approach. When I turn it off it first enters into a standby mode and after a few minutes it goes into semi-hibernation with a task scheduler. It's the difference between 2 seconds and picture and 10 seconds and picture when that switch occurs.

[aksdb]

Personally, if I need to power off a system, I like to always take the opportunity to do a full shutdown. I prefer doing this over hibernating as it means any memory leaks will be reset and any applications that have entered a non-intended erroneous state will be reset to an intentional and stable state. I know that neither of those two things should happen, but they sometimes do.

I guess that's why Microsoft took the middle ground with Windows 10 - which is probably the same that LG tries to do: shutting down user sessions (or even the whole user space) and hibernating the kernel. Though I guess for Linux the advantage would be quite small, since the kernel itself is quick enough already. Therefore we could only win some speed by keeping certain daemons and the whole init process "hibernated" (i.e. killing user sessions, but not the whole user space on shutdown and then hibernating the remaining system).

[skeevy420]

I guess that's why Microsoft took the middle ground with Windows 10 - which is probably the same that LG tries to do: shutting down user sessions (or even the whole user space) and hibernating the kernel. Though I guess for Linux the advantage would be quite small, since the kernel itself is quick enough already. Therefore we could only win some speed by keeping certain daemons and the whole init process "hibernated" (i.e. killing user sessions, but not the whole user space on shutdown and then hibernating the remaining system).

That's essentially what my TV described above does in its semi-hibernated state. Takes a while for the PC to detect it, takes a while for the panel to power on, and is basically off, but it does periodic scans for updates and can apply them in that state, can detect network changes, and probably other stuff that isn't obvious via network changes and the indicator light.

[[email protected]]

Hmm, from what I read, the bottleneck is essentially reading from disk.

Why do they need to read *everything* from disk at once? I would load everything asynchronously (especially on something that had good random read performance).
First read what's necessary to the kernel. Then let the scheduler resume its work while you are not done loading everything yet. Prioritize what the currently running program(s) need first.

That's essentially "mounting" the stored image as swap, and letting the system resume. I bet the current swap infrastructure can handle this just fine.

Or maybe I'm missing something? The idea here would be to load the pieces that aren't that useful last (example: that web browser in the background). Of course, it would be also nice to have a task-aware scheduler for this as well... (though the nice and ionice values are already good indicators).

[pal666]

That's essentially "mounting" the stored image as swap, and letting the system resume. I bet the current swap infrastructure can handle this just fine.

kernel can't be swapped out, only userspace. but i don't think smartphones have swap at all, so they are not writing it to swap, it looks like they are using raw(below translation layer) flash access

[carewolf]

My TV has a hybrid approach. When I turn it off it first enters into a standby mode and after a few minutes it goes into semi-hibernation with a task scheduler. It's the difference between 2 seconds and picture and 10 seconds and picture when that switch occurs.

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.

[SystemCrasher]

Boot time of 15 seconds isn't exactly masterpiece on anyhow modern SoC, to begin with. Say, my minimal Debian takes off in about 6 seconds on 1 GHz single-core ARM and is ready to serve. But, well, it doesn't brings heavy desktop libs and similar crap. Though I haven't really bothered to optimize what's "good enough". Yet its nowhere close to high-score someone eventually showcased, where Linux boots to Qt app in less than second (but they had to sacrifice a lot, giving up "init system" and rather making kernel to launch target app as "init"). So, uhm, I suggest LG to hire some "real" system engineers instead of throwing tantrums XD. And last but not least, "honest" cold boot is very useful to ensure clean, stable system state, no matter what. On other hand, suspended system would accumulate faults, and if hardware isn't high-end (ECC RAM, etc which makes it expensive) it could eventually get quite buggy.