Analysis: zram LZ4 dict compression patch feasibility (lore.kernel.org/lkml/ae51966c3cb445e9983230243bb6a5b2)

[pdscomp]

Summary

Feasibility analysis for applying the upstream patch:

zram: Optimize LZ4 dictionary compression performance
gao xu gaoxu2@honor.com, 2026-03-10

Findings

Patch: ❌ Does not apply to kernel 6.6.85

The patch targets a post-6.6 zram architecture that doesn't exist in our kernel:

• backend_lz4.c — file does not exist in 6.6.85
• struct zcomp_params — does not exist; 6.6.85 uses crypto_comp API
• comp_params_store() — function does not exist in zram_drv.c

Additionally, even if it could apply, the impact would be zero — dictionary compression is not configured on this device.

Kernel upgrade to 6.12 LTS: Feasible but non-trivial

6.12.80 LTS has the required zram backend architecture. Key upgrade risks:

• 4 out-of-tree patches need rebase validation (medium effort)
• meta-sunxi needs a new 6.12.x recipe
• R528/T113 SoC mainline coverage in 6.12 needs exploratory assessment

See docs/patch-analysis/zram-lz4-dict-compression.md for the full write-up.

[Copilot]

Pull request overview

Adds a documentation write-up assessing whether an upstream zram LZ4 dictionary-compression optimization patch can be applied to the project’s current kernel, and outlines what would be involved in moving to a kernel version where the patch architecture exists.

Changes:

• Add a feasibility analysis for applying the upstream zram LZ4 dictionary optimization patch to Linux 6.6.85.
• Document constraints preventing backporting (missing backend files / incompatible zram architecture) and note expected impact (dictionary compression not used).
• Provide a high-level risk/effort assessment for upgrading from 6.6.85 to 6.12 LTS to gain the required zram backend architecture.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The text says "Three patches" need re-validation, but the table lists 4 patches and later the effort summary also says "Rebase 4 out-of-tree patches". Please make the count consistent (likely "Four patches" here).

Suggested change

	Three patches in `meta-opencentauri` must be re-validated and potentially rebased against 6.12:
	Four patches in `meta-opencentauri` must be re-validated and potentially rebased against 6.12:

[jamesturton]

I think the path of least resistance here is to wait for Yocto 6.0 Wrynose to be released. Its due to be released this month although layers we depend on my take a little bit of time to official add compatibility with Wrynose, but it's probably best they do the testing not us. Wrynose will also give us lots of other nice benefits such as Rust 1.94.0 which supports 2024 edition so we can remove our dependency on meta-lts-mixins, pyhon 3.14 which offers numerous performance improvements and thermal support for cpu which atom currently has back-ported.

The only downside i see to updating to Wrynose is the increased resource requirements for the build machine due to using a newer LLVM compiler. The requirements can be seen here: https://docs.yoctoproject.org/migration-guides/release-notes-5.3.html#new-features-enhancements-in-yocto-ver