Incremental checkpointing of components

Denis Huber huber.denis at ...435...
Sun Jul 10 13:53:19 CEST 2016

Dear Genode-main readers,

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.

One aspect of the thesis is to store the (virtual) memory pages of B 
only if they were changed since the last checkpoint (known as 
"incremental checkpointing"). This means, I have to mark a page if it 
was used by a write access and unmark it after the checkpoint. This 
approach is similar to the dirty-bit mechanism in the MMU.

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.


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.

* Do I understand this approach correctly?
* Is there another way to be notified when a virtual memory page is 
* If not, is it possible to extend the core with this mechanism. If yes, 
which modules are involved?

Kind regards

More information about the users mailing list