37
edits
Changes
Jump to navigation
Jump to search
Line 9:
Line 9: − + + + − '''Summary:''' CRIU puts a lots of logs when doing its job. Logging is done with simple fprintf function. They are typically useless, but ''if'' some operation fails -- the logs are the only way to find what was the reason for failure.+ − + − At the same time the printf family of functions is known to take some time to work -- they need to scan the format string for %-s and then convert the arguments into strings. If comparing criu dump with and without logs the time difference is notable (15%-20%), so speeding the logs up will help improve criu performance.+ − − One of the solutions to the problem might be binary logging. The problem with binary logs is the amount of efforts to convert existing logs to binary form. Preferably, the switch to binary logging either keeps existing log() calls intact, either has some automatics to convert them. − − The option to keep log() calls intact might be in pre-compilation pass of the sources. In this pass each <code>log(fmt, ...)</code> call gets translated into a call to a binary log function that saves <code>fmt</code> identifier copies all the args ''as is'' into the log file. The binary log decode utility, required in this case, should then find the fmt string by its ID in the log file and print the resulting message. − + − * [[Better logging]]+ + + − + − + − + Line 57:
Line 57: − + Line 80:
Line 80: − * Suggested by: Alexander Mikhalitsyn <alexander@mihalicyn.com> − − === Add support for memfd_secret file descriptors === − − '''Summary:''' Support C/R of memfd_secret descriptors − − There is memfd_secret syscall which allows user to open − special memfd which is backed by special memory range which − is inaccessible by another processes (and the kernel too!). − − At the moment CRIU can't dump processes that have memfd_secret's opened. − − '''Links:''' − * https://lwn.net/Articles/865256/ − − '''Details:''' − * Skill level: intermediate − * Language: C − * Expected size: 350 hours − * Mentors: Alexander Mikhalitsyn <alexander@mihalicyn.com>, Mike Rapoport <mike.rapoport@gmail.com> Line 194:
Line 174: − + Line 211:
Line 191: + + + + + + + + + + + + + + + + + + + +
→Add support for checkpoint/restore of CORK-ed UDP socket
== Project ideas ==
== Project ideas ==
=== Optimize logging engine ===
=== Add support for memory compression ===
'''Summary:''' Support compression for page images
We would like to support memory page files compression
in CRIU using one of the fastest algorithms (it's matter
of discussion which one to choose!).
'''Links:'''
This task does not require any Linux kernel modifications
and scope is limited to CRIU itself. At the same time it's
complex enough as we need to touch memory dump/restore codepath
in CRIU and also handle many corner cases like page-server and stuff.
'''Details:'''
'''Details:'''
* Skill level: intermediate
* Skill level: intermediate
* Language: C, though decoder/preprocessor can be in any language
* Language: C
* Expected size: 350 hours
* Expected size: 350 hours
* Suggested by: Andrei Vagin
* Suggested by: Andrei Vagin <avagin@gmail.com>
* Mentors: Alexander Mikhalitsyn <alexander@mihalicyn.com>
* Mentors: Alexander Mikhalitsyn <alexander@mihalicyn.com>, Andrei Vagin <avagin@gmail.com>
=== Add support for checkpoint/restore of CORK-ed UDP socket ===
=== Add support for checkpoint/restore of CORK-ed UDP socket ===
* Language: C
* Language: C
* Expected size: 350 hours
* Expected size: 350 hours
* Mentors: Andrei Vagin <avagin@gmail.com>
* Mentors: Alexander Mikhalitsyn <alexander@mihalicyn.com>, Pavel Tikhomirov <ptikhomirov@virtuozzo.com>, Andrei Vagin <avagin@gmail.com>
=== Add support for pidfd file descriptors ===
=== Add support for pidfd file descriptors ===
* Expected size: 350 hours
* Expected size: 350 hours
* Mentors: Alexander Mikhalitsyn <alexander@mihalicyn.com>, Christian Brauner <christian@brauner.io>
* Mentors: Alexander Mikhalitsyn <alexander@mihalicyn.com>, Christian Brauner <christian@brauner.io>
* Suggested by: Alexander Mikhalitsyn <alexander@mihalicyn.com>
* Suggested by: Alexander Mikhalitsyn <alexander@mihalicyn.com>
'''Links:'''
'''Links:'''
* https://kubernetes.io/docs/concepts/extend-kubernetes/operator/
* https://github.com/checkpoint-restore/checkpoint-restore-operator
* https://kubernetes.io/docs/reference/node/kubelet-checkpoint-api/
* https://kubernetes.io/docs/reference/node/kubelet-checkpoint-api/
* https://kubernetes.io/blog/2022/12/05/forensic-container-checkpointing-alpha/
* https://kubernetes.io/blog/2022/12/05/forensic-container-checkpointing-alpha/
Listed here are tasks that seem suitable for GSoC, but currently do not have anybody to mentor it.
Listed here are tasks that seem suitable for GSoC, but currently do not have anybody to mentor it.
=== Optimize logging engine ===
'''Summary:''' CRIU puts a lots of logs when doing its job. Logging is done with simple fprintf function. They are typically useless, but ''if'' some operation fails -- the logs are the only way to find what was the reason for failure.
At the same time the printf family of functions is known to take some time to work -- they need to scan the format string for %-s and then convert the arguments into strings. If comparing criu dump with and without logs the time difference is notable (15%-20%), so speeding the logs up will help improve criu performance.
One of the solutions to the problem might be binary logging. The problem with binary logs is the amount of efforts to convert existing logs to binary form. Preferably, the switch to binary logging either keeps existing log() calls intact, either has some automatics to convert them.
The option to keep log() calls intact might be in pre-compilation pass of the sources. In this pass each <code>log(fmt, ...)</code> call gets translated into a call to a binary log function that saves <code>fmt</code> identifier copies all the args ''as is'' into the log file. The binary log decode utility, required in this case, should then find the fmt string by its ID in the log file and print the resulting message.
'''Links:'''
* [[Better logging]]
'''Details:'''
* Skill level: intermediate
* Language: C, though decoder/preprocessor can be in any language
* Expected size: 350 hours
* Suggested by: Andrei Vagin
* Mentors: Alexander Mikhalitsyn <alexander@mihalicyn.com>
=== IOUring support ===
=== IOUring support ===