Page MenuHomeFreeBSD
Files F152112407

D56319.diff
No OneTemporary
Actions

D56319.diff
View Options

diff --git a/website/content/en/status/report-2026-01-2026-03/hibernate.adoc b/website/content/en/status/report-2026-01-2026-03/hibernate.adoc
new file mode 100644
--- /dev/null
+++ b/website/content/en/status/report-2026-01-2026-03/hibernate.adoc
@@ -0,0 +1,31 @@
+=== Hibernate (aka Suspend-to-disk)
+
+Links: +
+link:https://github.com/OlCe2/freebsd-src/tree/oc-hibernate[Code for the initial prototype for saving the system image] URL: https://github.com/OlCe2/freebsd-src/tree/oc-hibernate +
+link:https://hackmd.io/50ygFG3qSmqMOKytJMuOGw?both=[Design document on the loader part of the resume process] URL: https://hackmd.io/50ygFG3qSmqMOKytJMuOGw?both=
+
+Contact: Olivier Certner <olce@FreeBSD.org> +
+Contact: Konstantin Belousov <kib@FreeBSD.org>
+
+Work is ongoing to have FreeBSD support hibernate (suspend-to-disk), without BIOS/firmware assistance to save the current machine state, for `amd64` UEFI-booted machines.
+
+The first phase was to make a prototype that saves a system image, at the moment putting aside consistency matters, so that parallel work can start on an EFI application meant to restore and bootstrap the saved image (Konstantin Belousov is working on this part).
+This phase was completed in March.
+A significant refactoring, in particular of the underlying dump infrastructure, needs to occur before that experimental code can be committed.
+
+The main next phase is to ensure consistency of the saved system image, so that the system is viable once restored.
+In a nutshell, the biggest constraint here is that we must ensure that no more I/O is in flight for several reasons, which consists in first ensuring that no more I/O requests can be created and then draining the existing requests.
+In particular, on-going DMA accesses could change memory while it is being saved, leading to out-of-date caching in the saved image.
+Also, if resuming fails (because of, e.g., some hardware consistency issue), I/O that did not reach stable storage would be lost, whereas application or filesystem code would expect them to be committed (loss of consistency).
+We have started identifying the subsystems that need attention and analyzing which changes are required in them (e.g., bus, GEOM, disk drivers).
+
+The phase after is to determine how to finally save the system image without tainting the consistency, as this operation itself modifies kernel memory.
+A first high-level possibility is to take a snapshot of memory after ensuring stability, and then resume normal operation to save the pages in their state at the moment the snapshot was taken.
+There are several possible refinements, such as forefront or lazy copying, with different implementation strategies, and thus characteristics and requirements.
+Advantages of snapshotting include the ability to use regular kernel code to save the image, with all available transformations supported.
+Drawbacks are higher memory consumption, although that depends a lot on the chosen implementation strategy and seems to be mitigable for a large part, and possibly some complications at very low levels of the kernel.
+An alternative which is under study is not to snapshot, but instead ensure that sending the image to disk only modifies state that will be effectively reset on resume.
+This alternative requires implementation of selective suspend, but otherwise we expect that a large part of the existing dump-on-panic code would be reusable.
+We are currently digging into the different options to better understand their feasibility and the trade-offs involved.
+
+Sponsor: The FreeBSD Foundation

File Metadata

Mime Type
text/plain
Expires
Mon, Apr 13, 7:40 PM (15 m, 16 s)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
31422797
Default Alt Text
D56319.diff (3 KB)

Event Timeline