Identifying pages that won't be written while tasks are frozen
Identifying pages that won't be written while tasks are frozen
Posted Aug 9, 2007 7:40 UTC (Thu) by xoddam (subscriber, #2322)Parent article: Suspend and hibernation status report
> ... usually there are many saveable pages in the system
> that will not be accessed when userland processes are frozen,
> and in principle these pages could be included in the
> hibernation image without copying. Unfortunately, however,
> no efficient method of identifying them pages has been
> proposed yet. If you have any ideas and/or hints, please help.
Identifying pages that won't change doesn't need to be
very efficient if it lets you avoid evicting enough pages
that you have half the system RAM free then *copying*
every remaining page!
*No* userspace memory should be touched with devices suspended
and tasks frozen ... what's wrong with marking all user pages
copy-on-write? You have to thaw & resume in order to do things
to the image as it is written to disk (if the hibernation
is driven from userspace), but copy-on-write ought to be
sufficient for this to work with only a fraction of the
RAM available, shouldn't it? And if writing the image
is done from within the kernel without running any userspace
tasks at all, surely there's not even a risk of mapped pages
changing?
Does the page cache somehow throw a spanner in the works?
You need to *write* the image to disk, but surely you have
complete discretion over the cache ... you can evict the
lot or preserve as much as you choose, even create a new
cache after making the 'atomic' copy of kernel memory...
There must be some consideration I'm missing.