mirror of
https://github.com/checkpoint-restore/criu
synced 2025-08-30 05:48:05 +00:00
f3bee6d584
It turned out, that fdopen (used in fopen_proc) always maps a 4k buffer for reads and this buffer gets unmap-ed later on fclose. Taking into account the amount of proc files we read (~20 per task plus one file per opened file descriptor) this mmap+munmap result in quite a lot of useless CPU time. E.g. for a container of 20 tasks we have 1000 calls taking ~8% of total dump time. So lets first stop doing this for simple cases -- one line proc files. Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
criu ==== An utility to checkpoint/restore tasks. Using this tool, you can freeze a running application (or part of it) and checkpoint it to a hard drive as a collection of files. You can then use the files to restore and run the application from the point it was frozen at. The distinctive feature of the CRIU project is that it is mainly implemented in user space. The project home is at http://criu.org Pages worth starting with are * Kernel configuration, compilation, etc: http://criu.org/Installation * A simple example of usage: http://criu.org/Simple_loop * More sophisticated example with graphical app: http://criu.org/VNC