> I do like the fact that swsusp2 resumes with caches and buffers intact.
> If I wanted to wait while the system painfully restored this data one 4K
> page fault from swap at a time, I might as well reboot--it could actually
> be faster.
Me too. But on my machine (laptop - harddisk is slow) rebooting would still be slower ;-)
> On the other hand, I generally like to run a small application before
> suspending, which allocates memory until a few hundred pages are swapped
> (it is a loop of malloc() and reading paging statistics out of /proc),
> then exits. This dumps out some of the more useless 400MB or so of caches
> on my system, and cuts resume time in half (it does add a second or two
> to suspend), without the extreme pain of having to swap _everything_ back
> in on resume.
Isn't that exactly what the # ImageSizeLimit 200 item in hibernate.conf (or the /proc/software_suspend/image_size_limit respectively) are there for?
Does your way of doing the more or less same thing have an advantage over that? (Faster maybe?)
> I'm not sure what benefit there is in pushing too much of the suspend and
> resume functions into user space.
I agree here. Because it still seems to need very much code in the kernel - only a minimal part is user space application.
And I don't really like it if the kernel depends on user space apps to boot - only makes for trouble (the tool has to be on the initrd (I don't like initrds anyway - at least not for my custom built kernels))
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds