From: jinji zhong <jinji.z.zhong@gmail.com>
To: minchan@kernel.org, senozhatsky@chromium.org,
philipp.reisner@linbit.com, lars.ellenberg@linbit.com,
christoph.boehmwalder@linbit.com, corbet@lwn.net, tj@kernel.org,
hannes@cmpxchg.org, mkoutny@suse.com, axboe@kernel.dk,
mhocko@kernel.org, roman.gushchin@linux.dev,
shakeel.butt@linux.dev, akpm@linux-foundation.org,
terrelln@fb.com, dsterba@suse.com
Cc: muchun.song@linux.dev, linux-kernel@vger.kernel.org,
drbd-dev@lists.linbit.com, linux-doc@vger.kernel.org,
cgroups@vger.kernel.org, linux-block@vger.kernel.org,
linux-mm@kvack.org, zhongjinji@honor.com, liulu.liu@honor.com,
feng.han@honor.com, jinji zhong <jinji.z.zhong@gmail.com>
Subject: [RFC PATCH 0/3] Introduce per-cgroup compression priority
Date: Sun, 26 Oct 2025 01:05:07 +0000 [thread overview]
Message-ID: <cover.1761439133.git.jinji.z.zhong@gmail.com> (raw)
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
next reply other threads:[~2025-10-26 1:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-26 1:05 jinji zhong [this message]
2025-10-26 1:05 ` [RFC PATCH 1/3] mm/memcontrol: Introduce per-cgroup compression priority jinji zhong
2025-10-26 1:05 ` [RFC PATCH 2/3] zram: Zram supports " jinji zhong
2025-10-26 1:05 ` [RFC PATCH 3/3] Doc: Update documentation for " jinji zhong
2025-10-27 16:06 ` [RFC PATCH 0/3] Introduce " Tejun Heo
2025-10-30 9:22 ` zhongjinji
2025-10-27 17:29 ` Shakeel Butt
2025-10-30 11:32 ` zhongjinji
2025-10-27 22:46 ` Nhat Pham
2025-10-28 3:31 ` Sergey Senozhatsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1761439133.git.jinji.z.zhong@gmail.com \
--to=jinji.z.zhong@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=cgroups@vger.kernel.org \
--cc=christoph.boehmwalder@linbit.com \
--cc=corbet@lwn.net \
--cc=drbd-dev@lists.linbit.com \
--cc=dsterba@suse.com \
--cc=feng.han@honor.com \
--cc=hannes@cmpxchg.org \
--cc=lars.ellenberg@linbit.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liulu.liu@honor.com \
--cc=mhocko@kernel.org \
--cc=minchan@kernel.org \
--cc=mkoutny@suse.com \
--cc=muchun.song@linux.dev \
--cc=philipp.reisner@linbit.com \
--cc=roman.gushchin@linux.dev \
--cc=senozhatsky@chromium.org \
--cc=shakeel.butt@linux.dev \
--cc=terrelln@fb.com \
--cc=tj@kernel.org \
--cc=zhongjinji@honor.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).