[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200704272244.08102.rjw@sisk.pl>
Date: Fri, 27 Apr 2007 22:44:07 +0200
From: "Rafael J. Wysocki" <rjw@...k.pl>
To: Pekka J Enberg <penberg@...helsinki.fi>
Cc: Nigel Cunningham <nigel@...el.suspend2.net>,
Linus Torvalds <torvalds@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: Back to the future.
On Friday, 27 April 2007 06:52, Pekka J Enberg wrote:
> On Thu, 2007-04-26 at 09:56 -0700, Linus Torvalds wrote:
> > > which will map in the snapshot, return the mapped address and the size
> > > (and if you want to support snapshots > 4GB, be my guest, but I suspect
> > > you're actually *better* off just admitting that if you cannot shrink
> > > the snapshot to less than 32 bits, it's not worth doing)
>
> On Fri, 27 Apr 2007, Nigel Cunningham wrote:
> > That inherently limits the image to half of available ram (you need
> > somewhere to store the snapshot), so you won't get the full image you
> > express interest in below.
>
> It doesn't. We can make the userspace mapped pages copy-on-write. As long
> as the userspace makes sure there's not much activity during
> snapshot/shutdown, we will be fine. What we probably do need to copy is
> kernel pages.
The user space is (and IMHO should be) frozen way before that and what you're
suggesting here is what I wanted to implement some time ago. The problem with
this was that the user space pages may be updated, for example, by device
drivers as a result of some deferred I/O after we've snapshotted the system.
I didn't know how to find out which pages owned by the user space could be
updated this way, so I gave up at that time.
Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists