[GSoC 2026] [RFC] mm: Add memory compression support using Decorator pattern (PoC)

[DongSunchao]

Summary

This is a Proof-of-Concept (PoC) implementation for the GSoC 2026 project: "Add support for memory compression".

This PR introduces a Decorator Pattern to hook into the page-xfer layer. It allows transparent compression of memory pages during checkpointing without modifying the core mem.c logic or function signatures.

Key Implementation Details

1. Decorator Pattern:

   • Intercepts open_page_xfer to inject a compression layer (criu/page-xfer-compress.c).
   • Wraps the underlying transport (e.g., local file write or page-server).

2. Buffering Strategy:

   • Implemented a 64KB write buffer to aggregate small page writes.
   • This solves the low-compression-ratio issue and ensures efficient LZ4 block compression.
   • Handles partial writes and loops correctly to support large memory chunks.

3. Data Flow:
   mem.c (write_pages) -> Compress Buffer -> LZ4 -> orig_xfer->write_pages (Compressed Blob with Header)

Verification (PoC Status)

I have verified the implementation with a live dump process. The logs confirm that the decorator successfully intercepts the memory stream and compresses data.

Results observed:

• Successfully initialized the compression decorator via --compress-lz4.
• Compression Ratio: Observed ratios between 2.6x and 10x (e.g., compressing 64KB chunks down to ~6KB or ~24KB depending on data entropy).
• Stability: The dump process completes successfully without crashing.

Pending / GSoC Roadmap

This PoC focuses on the Dump path. The planned work for the GSoC period includes:

• Implementing the Restore path (Decompression buffer & cache).
• Handling pagemap offset corrections (currently pass-through).
• Adding support for other algorithms (e.g., Zstd).
• Adding standard ZDTM regression tests.

Feedback Needed

I would appreciate feedback on the architectural approach (Decorator + Buffer). Is this the direction the team prefers for isolating compression logic?

Signed-off-by: dong sunchao [dongsunchao@gmail.com]

[rst0git]

This PR introduces a Decorator Pattern to hook into the page-xfer layer. It allows transparent compression of memory pages during checkpointing without modifying the core mem.c logic or function signatures.

@DongSunchao We use a slightly different approach to implement compression support in CRIU. The following presentation provides more information: https://lpc.events/event/19/contributions/2236/

[DongSunchao]

@rst0git I‘ve been analyzing the CRaC fork deeply. I'm really glad we choose the same algorithm(LZ4).

While the CRaC implementation is a great reference(especially using the stardand LZ4 function to replace LZ4_compress_default), I noticed it decompresses to the stack and relies on tempoary files, which case poor perfermance.

My plan is to implement a streaming approach with an Index Table.
Basically, I'll map the logical pages to their physical compressed offsets in an index. During restore, I'll use a decompression buffer to handle the random access required by lazy restore.

This should allow criu to process the large images (16G+) rather than failing with out-of-memory.

[rst0git]

@DongSunchao I think there may have been a misunderstanding about the presentation - CRaC's compression mechanism is not intended as a reference; it is used only as a baseline for our evaluation. The following pull request implements the functionality shown in the presentation: #2895

[DongSunchao]

@rst0git Thank you for the clarification. I've carefully reviewed #2895 . I now basically understand how it implements the compression and uncompression by page_size size blocks and uses pipes to read and write.

However, I believe we can improve the implementation by using the Decorator pattern instead of adding more logic into prepare_vma_ios.

[DongSunchao]

Hi @rst0git, @avagin , @Snorch ,

I noticed that the 'Add support for memory compression' idea was recently removed from the GSoC 2026 ideas list.

Since I have been actively working on this PoC and am highly passionate about implementing this feature for GSoC, I wanted to quickly check the status of this idea.

If it was removed because the technical scope or priority of CRIU has changed, could you let me know? I would be very happy to pivot to another high-priority issue or adjust my current proposal to better align with your needs.

If it is still a valid project but just hidden from the main list, I will continue refining this PoC and my proposal based on any feedback you might have.

Thank you for your time and guidance!

[rst0git]

@DongSunchao Thank you for working on this and you are more than welcome to contribute! We added this project idea for last year's GSoC, and since then I have been working on this as part of my PhD research. It is of relatively high priority for us, as we plan to integrate this functionality also with support for encryption. Both features are relatively complex and require extensive testing before we can merge them upstream.

For now we decided to remove the project idea from the list to avoid duplicating efforts. I would be happy to help with the application process for GSoC, please reach out if you have any questions!

[DongSunchao]

@rst0git Thank you so much for the clarification! It makes sense to remove the idea to avoid duplicating the core work of your PhD research.

I really appreciate the detailed discussions and the materials you offered. Analyzing PR #2895 and discussing the IO pipeline/daemon architecture has been a fantastic learning experience and helped me understand CRIU's internals much better.

As you kindly suggested, I will trun to another active idea on the list. I will follow up with you via email regarding my application and the new direction. Thanks again for your time and guidance!