lkml.org 
[lkml]   [2003]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Software Suspend Functionality in 2.5
On Fri, Feb 28, 2003 at 07:16:31AM +1300, Nigel Cunningham wrote:
> Hi.
>
> I've looked at LKCD and seen that they have a provision for compressing
> the pages which are written. Ideally, I'd like to see us sharing code
> because I reckon there's a fair bit in common between the two projects.
> For the moment, though, I haven't seriously considered implementing
> compression. I've just been concentrating on getting things as stable as
> possible under 2.4 (given that there's no driver model there), and
> beginning to seek to port the changes to 2.5. Perhaps compression could
> be added later, but I am worrying about the basics (getting the pages
> saved in any form!) first.

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/

\
 
 \ /
  Last update: 2005-03-22 13:33    [W:0.043 / U:13.600 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site