linux-kernel - [RFC PATCH 0/3] Introduce per-cgroup compression priority

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <cover.1761439133.git.jinji.z.zhong@gmail.com>
Date: Sun, 26 Oct 2025 01:05:07 +0000
From: jinji zhong <jinji.z.zhong@...il.com>
To: minchan@...nel.org,
	senozhatsky@...omium.org,
	philipp.reisner@...bit.com,
	lars.ellenberg@...bit.com,
	christoph.boehmwalder@...bit.com,
	corbet@....net,
	tj@...nel.org,
	hannes@...xchg.org,
	mkoutny@...e.com,
	axboe@...nel.dk,
	mhocko@...nel.org,
	roman.gushchin@...ux.dev,
	shakeel.butt@...ux.dev,
	akpm@...ux-foundation.org,
	terrelln@...com,
	dsterba@...e.com
Cc: muchun.song@...ux.dev,
	linux-kernel@...r.kernel.org,
	drbd-dev@...ts.linbit.com,
	linux-doc@...r.kernel.org,
	cgroups@...r.kernel.org,
	linux-block@...r.kernel.org,
	linux-mm@...ck.org,
	zhongjinji@...or.com,
	liulu.liu@...or.com,
	feng.han@...or.com,
	jinji zhong <jinji.z.zhong@...il.com>
Subject: [RFC PATCH 0/3] Introduce per-cgroup compression priority

Hello everyone,

On Android, different applications have varying tolerance for
decompression latency. Applications with higher tolerance for
decompression latency are better suited for algorithms like ZSTD,
which provides high compression ratio but slower decompression
speed. Conversely, applications with lower tolerance for
decompression latency can use algorithms like LZ4 or LZO that
offer faster decompression but lower compression ratios. For example,
lightweight applications (with few anonymous pages) or applications
without foreground UI typically have higher tolerance for decompression
latency.

Similarly, in memory allocation slow paths or under high CPU
pressure, using algorithms with faster compression speeds might
be more appropriate.

This patch introduces a per-cgroup compression priority mechanism,
where different compression priorities map to different algorithms.
This allows administrators to select appropriate compression
algorithms on a per-cgroup basis.

Currently, this patch is experimental and we would greatly
appreciate community feedback. I'm uncertain whether obtaining
compression priority via get_cgroup_comp_priority in zram is the
best approach. While this implementation is convenient, it seems
somewhat unusual. Perhaps the next step should be to pass
compression priority through page->private.

jinji zhong (3):
  mm/memcontrol: Introduce per-cgroup compression priority
  zram: Zram supports per-cgroup compression priority
  Doc: Update documentation for per-cgroup compression priority

 Documentation/admin-guide/blockdev/zram.rst | 18 +++--
 Documentation/admin-guide/cgroup-v2.rst     |  7 ++
 drivers/block/zram/zram_drv.c               | 74 ++++++++++++++++++---
 drivers/block/zram/zram_drv.h               |  2 +
 include/linux/memcontrol.h                  | 19 ++++++
 mm/memcontrol.c                             | 31 +++++++++
 6 files changed, 139 insertions(+), 12 deletions(-)

-- 
2.48.1