The thought was that with compression you can copy more pages
into the same free memory space; meaning that you need to
free up far less pages. If you are lucky enough, you might
get to resume from very close to the state you suspended and
hence avoid the initial sluggishness on resume.
But yes, you've rightly guessed that my question did stem from
what we are doing on LKCD. People have asked me if we could
reuse swsusp logic, and even I'd thought about that way back
when swsusp started for 2.5. I remember talking to Pavel about
it last year at OLS - hoping it could save some work for
us :)
The problem was that we have to deal with far more stringent
conditions in a crash dump situation, and the very things that
seemed like interesting ideas or neat twists in swsusp (like
the trick of freeing-up enough pages to be able to an atomic
suspend-to-ram, or maybe even the refridgerator concept),
just couldn't work or apply in that situation.
Aside of the fact that we can't swapout at that point of
time, we do want a near-exact snapshot of memory. And we are
ambitious enough to want to be able to snapshot full memory
or as close as possible to that, if so required.
Since we've had to work on a solution that can be used
for accurate non-disruptive dumps as well as crash dumps
(the latter using kexec), I was wondering whether it
was worth exploring possibilities of commonality with
swsusp down the line ... I know its not probably not
something very immediate, but just an indication on
whether we should keep applicability for swsusp (probably
reuse and share ideas/code back and forth between the
two efforts) in mind as we move forward. Because we
have to support a more restrictive situation when it
comes to dumping, it just may be usable by swsusp too
if we can get it right.
Regards
Suparna
>
> On Fri, 2003-02-28 at 01:42, Suparna Bhattacharya wrote:
> > Nigel,
> >
> > When I noticed some of your discussions on swsusp mailing
> > list earlier, a question that crossed my mind was whether
> > you'd thought about the possibility of compression of data
> > at the time of copy.
> >
> > Would that have been another way to helped achieve the
> > objective you have in mind ? Do any issues come to mind ?
> >
> > Regards
> > Suparna
> >
>
>
-- Suparna Bhattacharya (suparna@in.ibm.com) Linux Technology Center IBM Software Labs, India- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/