Incremental checkpointing of components

[Norman Feske]

Hi Denis,

> I am working on my thesis to implement a real-time capable 
> checkpoint/restore mechanism in Genode/L4-Fiasco.OC on the Chair of 
> Operating Systems, TUM Department of Informatics. A checkpoint
> component A has to transparently (more or less) store the internal
> state of another component B and restore it on another machine also
> running Genode.

let me refer to a recent discussion (back in March) that was closely
related to the topic:


https://sourceforge.net/p/genode/mailman/genode-main/thread/CAPyx70Cy_v3WBcqtsBuN5r%3DDwBDM_xH6COq_Z86aubHYdYR_3w%40mail.gmail.com/#msg34991766

to motivate your work, I would recommend you to state a tangible goal,
i.e., an concrete example scenario that you want to realize. My
sentiment is that many supposed use cases of a general checkpointing
mechanism can be addressed differently and simpler on Genode. Please
take the line of thinking that I presented as the second approach in the
discussion above into consideration.

That said, I still find it worthwhile to experiment with the design and
implementation of such a mechanism. Don't let me discourage you. ;-)

> By searching the genode-main mailing list I found an idea for emulating 
> the dirty-bit mechanism. In the message [1], the author suggests the use 
> of managed dataspaces and a custom RAM service. The RAM server detaches 
> a dataspace which a client is using, re-attaches and marks the dataspace 
> when the client wants to read it or write to it. Thus, the server of the 
> RAM service notices whenever a client uses a specific dataspace.
> 
> [1] https://sourceforge.net/p/genode/mailman/message/34787057/
> 
> The problem of this approach is the granularity of the dataspaces. I 
> want to be notified when a virtual memory page is changed and store only 
> this page. But using one RM session per 4 KiB dataspace (typical page 
> size) is not efficient, because an RM session uses 64 KiB for itself.

This has changed in Genode 16.05. Now, one RM session can be used to
create many managed dataspaces. Thereby, managed dataspaces have become
much cheaper. The former functionality of the' Rm_session' has moved to
'Region_map'. Each PD is readily equipped with 3 region maps. The new
'Rm_session' interface allows the client to create further region caps.
See the section in the release notes [1]. Please also consider to follow
the changes I made in the new revision of the book [2] for version 16.05.

[1]
http://genode.org/documentation/release-notes/16.05#Consolidation_of_core_s_SIGNAL__CAP__RM__and_PD_services
[2]
https://github.com/nfeske/genode-manual/commit/7c165e92697932d2433e00316e5c9cfb60c8a56d

> * Do I understand this approach correctly?
> * Is there another way to be notified when a virtual memory page is 
> accessed?

Not via the Genode API. If you tie your work to a specific kernel, there
may be additional kernel-specific mechanisms you could use. E.g.,
virtualization components like L4Linux (Fiasco.OC) , Seoul (NOVA), or
VirtualBox (NOVA) invoke the kernel interface directly to manage a guest OS.

> * If not, is it possible to extend the core with this mechanism. If yes, 
> which modules are involved?

I cannot give you a single true answer. There may be various designs
possible, ranging from no modifications of core at all (e.g., via the
approach followed by the Noux runtime or the RAM-server mentioned in the
discussion you mentioned), over the use of a kernel-specific
virtualization feature (monitoring the to-be-checkpointed component at a
very low level like a virtual machine), to the extension of core's
PD-session interface with a serialization/de-serialization feature. I am
sure there are even plenty of more options.

Cheers
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth