Page MenuHomeFreeBSD
Files F156508315

D56319.id175150.diff
No OneTemporary
Actions

D56319.id175150.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,49 @@
+=== Hibernate (aka Suspend-to-disk)
+
+Contact: Olivier Certner <olce@FreeBSD.org>
+
+Work is ongoing to have FreeBSD support hibernate (suspend-to-disk) without
+BIOS/firmware assistance to save the current machine state.
+
+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
+works 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 does only modify 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 the different options to better understand their
+feasibility and the trade-offs involved.
+
+Sponsor: The FreeBSD Foundation

File Metadata

Mime Type
text/plain
Expires
Fri, May 15, 6:16 AM (12 h, 51 m)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
31170388
Default Alt Text
D56319.id175150.diff (3 KB)

Event Timeline