[RFC][PATCH 2/2] CR: handle a single task with private memory maps

Louis Rilling Louis.Rilling at kerlabs.com
Tue Aug 5 02:32:38 PDT 2008

On Mon, Aug 04, 2008 at 10:37:20PM -0400, Oren Laadan wrote:
> Louis Rilling wrote:
>> On Fri, Aug 01, 2008 at 02:51:57PM -0400, Oren Laadan wrote:
>>> Louis Rilling wrote:
>>>> On Fri, Aug 01, 2008 at 10:15:26AM -0400, Oren Laadan wrote:
>>> I actually wasn't thinking of streaming a series of incremental checkpoints
>>> (from base and on) to implement migration... I simply didn't have a use-case
>>> for that :)
>> This could be useful however. Since incremental checkpoint is faster
>> this could reduce down-time.
> Naturally incremental checkpoint reduces downtime; however since each checkpoint
> is taken at a different time, they can be streamed -- transferred over the
> network -- as they are taken. This gives more flexibility and can still, if
> you wish, can easily be transformed to a single long stream.
> Actually, this is a good argument in favor of using multiple files: they are a
> more flexible approach and can always be easily transformed to a single long
> stream, while the reverse isn't so.

Yes the reverse is as easy: rebuilding a full checkpoint of a given id
#id consists simply in removing the records that are tagged as invalid as
from checkpoints having ids <= #id. This is actually what restart should
do :)

>>>> The point is that you need previous data when building an incremental
>>>> checkpoint, so you will read it at least. And since it was previously stored (in
>>> The scheme that I described above and is implemented in Zap does not require
>>> access to previous checkpoints when building a new incremental checkpoint.
>>> Instead, you keep some data structure in the kernel that describes the pieces
>>> that you need to carry with you (what pages were saved, and where; when a task
>>> exits, the data describing its mm will be discarded, of course, and so on).
>> This is because you probably decided that a mechanism in the kernel that saves
>> storage space was not interesting if it does not improve speed. As a
>> consequence you need to keep metadata in kernel memory in order to do
>> incremental checkpoint. Maybe saving storage space without considering
>> speed could equally be done from userspace with sort of checkpoint diff
>> tools that would create an incremental checkpoint 2' from two full
>> checkpoints 1 and 2.
> Good point. In fact, the meta data is not only kept in memory, but also saved
> with each incremental checkpoint (well, its version at checkpoint time), so
> that restart would know where to find older data. So it is already transfered
> to user space; we may as well provide the option to keep it only in user space.

That is userspace should give it back to the kernel before doing the
next incremental checkpoint?


Dr Louis Rilling			Kerlabs - IRISA
Skype: louis.rilling			Campus Universitaire de Beaulieu
Phone: (+33|0) 2 99 84 71 52		Avenue du General Leclerc
Fax: (+33|0) 2 99 84 71 71		35042 Rennes CEDEX - France

More information about the Containers mailing list