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.
[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.
* Do I understand this approach correctly?
* Is there another way to be notified when a virtual memory page is
accessed?
* If not, is it possible to extend the core with this mechanism. If yes,
which modules are involved?
Kind regards
Denis
More information about the users
mailing list