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

[Louis Rilling]

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?

Louis

-- 
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
http://www.kerlabs.com/
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers