Description
The Containers and Checkpoint/Restore Microconference focuses on both userspace and kernel related work. The micro-conference targets the wider container ecosystem ideally with participants from all major container runtimes as well as init system developers.
Contributions to the micro-conference are expected to be problem statements, new use-cases, and feature proposals both in kernel- and userspace.
The user namespace currently relies on mapping UIDs and GIDs from the initial namespace (full uint32 range) into the newly created user namespace. This is done through the use of uid_map/gid_map with the kernel allowing mapping your own uid/gid and otherwise requiring a privileged process write a more complete map.
As more and more software (not just container managers) are making use of...
Mount checkpoint/restore is an important part of CRIU, it is responsible for
consistency of the file system view of dumped processes. In current state we
can only restore simple mount configurations, something more complex would
either make us fail or, which is even worse, make us creating wrong file
system view for restored processes.
In CRIU we only see the final state, the result of...
Starting things is slow. Even if only 1 second slow, saving 1s on a million container restores means we can save 11 days of useless work that every container will perform identically.
That's where snapshots come in. Snapshots in theory allow us to save an initialized container once, but then restore it a million times at less overhead than cold starting it takes.
Unfortunately, Linux...
We recently announced our work to support Checkpoint and Restore with AMD GPUs. This was first time a device plugin is introduced and that deals with one of the most complex devices on the system i.e. GPU. We made several changes to CRIU, introduced new plugin hooks and reported some issues with CRIU.
https://github.com/RadeonOpenCompute/criu/tree/amd-criu-dev-staging/plugins/amdgpu#readme...
CRIU uses many different interfaces to get information about kernel resources,
to extract sockets data sock_diag subsystem is used, for mounts/mount namespaces,
procfs per-pid mountinfo files are used, to get some file type-specific info we
use procfs fdinfo interface (which allows to get mnt_id from which file was opened,
file flags and so on).
One of the most important and...
