Enable Checkpoint/restore support by default in the kernel

[FDelporte]

Describe the bug

I asked this question on the Forum, but got no reaction, so moving it to here...
https://forums.raspberrypi.com/viewtopic.php?t=352607

While experimenting with CRaC (Coordinated Restore at Checkpoint, see https://docs.azul.com/core/crac/crac-introduction) we found out that "Checkpoint/restore support" is not enabled in the kernel. We validated with a custom build of OpenJDK that we can get this working in Raspberry Pi OS by recompiling the kernel with this option enabled.

Steps to reproduce the behaviour

The whole process of trying CRaC with CRIU is described on, with screenshots of the required changes in the kernel configuration:
https://webtechie.be/post/2023-06-15-crac-on-raspberry-pi/

It proves that enabling Checkpoint/restore support in the kernel allows to use CRaC in Java.

Device (s)

Raspberry Pi 4 Mod. B

System

$ cat /etc/rpi-issue
Raspberry Pi reference 2023-05-03
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 7c750947a959fb626a70c09fd17c65815df192ac, stage

$ vcgencmd version
Mar 17 2023 10:50:39
Copyright (c) 2012 Broadcom
version 82f3750a65fadae9a38077e3c2e217ad158c8d54 (clean) (release) (start)

$ uname -a
Linux raspberrypi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux

Logs

No response

Additional context

No response

[pelwell]

You're asking for CONFIG_CHECKPOINT_RESTORE=y to be added to our defconfig(s).

1. To which platforms should this be added? 64-bit only?
2. The kernel size barely alters as a result of adding this option being enabled (the uncompressed image seems not to change at all, which is odd), but have you seen any performance differences? Ubuntu seem to set it by default, so it can't be terrible.

Any concerns, @popcornmix?

[FDelporte]

Thanks for your feedback!

1/ CRaC is only available for 64-bit systems, so regarding this ticket and this use case, yes, only 64-bit.
2/ AFAIK CRIU only "comes in action" when a checkpoint needs to be created. So I don't see why it should impact performance. But I'm absolutely no expert on this topic.

[FDelporte]

@pelwell as far as I understand the project, the only change is indeed adding CONFIG_CHECKPOINT_RESTORE=y to bcm2711_defconfig. Should I create a pull request with this change?

[pelwell]

That won't be necessary. Adding the config settings is easy, it's weighing up the pros and cons and making a decision that is difficult, especially when there are other demands on ones time.

[FDelporte]

Thanks, @pelwell, and I understand. From my point of view, I only see the pro of adding this option, of course ;-)

[pelwell]

I'm hoping to get some time go through a bunch of similar requests in the near future. I think this one is likely to be a "yes", but I'm not making any promises.

[pelwell]

After kicking the tires on a freshly built kernel with CHECKPOINT_RESTORE enabled, I can't see any obvious performance hits. The code changes are mainly adding functionality rather than altering existing paths, either adding new switch() cases or providing real implementations for what used to be dummy functions. The uncompressed kernel size does not change at all, and the compressed grows by less than 5kB.

The new option has been added to the arm64 bcm2711_defconfig, and will appear in future kernel releases.

[FDelporte]

Thanks a lot @pelwell !!!