[lkml]   [2003]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Software Suspend Functionality in 2.5

> > > 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.
> >
> > Well, less code duplication is always welcome. But notice we need
> > *atomic* snapshots in swsusp, else we might corrupt data.
> Atomic snapshots are what we'd like for dump too, since we desire
> accurate dumps (minimum drift), so its not a conflicting requirement.
> The difference is that while you could do i/o (e.g to flush pages
> to free up memory) before initiating an atomic snapshot, we can't.

OTOH "best-effort-atomic" is probably okay for you, while it is not
acceptable for swsusp. Hopefully the code is not going to get too
complicated by "must be atomic" and "must work with crashed system"

Horseback riding is like software...
...vgf orggre jura vgf serr.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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