linux-kernel - Re: [RFC PATCH v3 7/8] mm/zswap: compressed ram direct integration

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-prev] [day] [month] [year] [list]

Message-ID: <a3zwoccozpnpum3dkvdytjl4aookymmuuhzcnswznxft5jy6mi@wfcyp4euizrx>
Date: Thu, 15 Jan 2026 22:09:26 +0000
From: Yosry Ahmed <yosry.ahmed@...ux.dev>
To: Gregory Price <gourry@...rry.net>
Cc: linux-mm@...ck.org, cgroups@...r.kernel.org, linux-cxl@...r.kernel.org, 
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
	kernel-team@...a.com, longman@...hat.com, tj@...nel.org, hannes@...xchg.org, 
	mkoutny@...e.com, corbet@....net, gregkh@...uxfoundation.org, rafael@...nel.org, 
	dakr@...nel.org, dave@...olabs.net, jonathan.cameron@...wei.com, 
	dave.jiang@...el.com, alison.schofield@...el.com, vishal.l.verma@...el.com, 
	ira.weiny@...el.com, dan.j.williams@...el.com, akpm@...ux-foundation.org, 
	vbabka@...e.cz, surenb@...gle.com, mhocko@...e.com, jackmanb@...gle.com, 
	ziy@...dia.com, david@...nel.org, lorenzo.stoakes@...cle.com, 
	Liam.Howlett@...cle.com, rppt@...nel.org, axelrasmussen@...gle.com, yuanchu@...gle.com, 
	weixugc@...gle.com, yury.norov@...il.com, linux@...musvillemoes.dk, 
	rientjes@...gle.com, shakeel.butt@...ux.dev, chrisl@...nel.org, kasong@...cent.com, 
	shikemeng@...weicloud.com, nphamcs@...il.com, bhe@...hat.com, baohua@...nel.org, 
	chengming.zhou@...ux.dev, roman.gushchin@...ux.dev, muchun.song@...ux.dev, 
	osalvador@...e.de, matthew.brost@...el.com, joshua.hahnjy@...il.com, 
	rakie.kim@...com, byungchul@...com, ying.huang@...ux.alibaba.com, 
	apopple@...dia.com, cl@...two.org, harry.yoo@...cle.com, zhengqi.arch@...edance.com
Subject: Re: [RFC PATCH v3 7/8] mm/zswap: compressed ram direct integration

On Thu, Jan 15, 2026 at 12:26:41PM -0500, Gregory Price wrote:
> > > For the first go, yeah.  A cram.c would need special page table handling
> > > bits that will take a while to get right.  We can make use of the
> > > hardware differently in the meantime.
> > 
> > Makes sense.
> > 
> > I just want to point out that using compressed memory with zswap doesn't
> > buy us much in terms of reclaim latency, so the main goal here is just
> > saving memory on the top tier, not improving performance, right?
> >
> 
> Yeah first goal is to just demonstrate such an accelerator can even work
> as a top-tier memory saving mechanism.  But hard to say whether reclaim
> latency will be affected appreciably - won't know until we get there :]
> 
> I'm totally prepared for this to be a science experiment that gets
> thrown away.

If that's the case I would put the zswap stuff under an experimental
config option that's not enabled by default, so that we can rip it out
later if needed. 

> 
> > > 
> > > I will probably need some help to get the accounting right if I'm being
> > > honest.  I can't say I fully understanding the implications here, but
> > > what you describe makes sense.
> > > 
> > 
> > Yeah it's counter-intuitive. Zswap needs to charge less than PAGE_SIZE
> > so that memcg tracking continues to make sense with reclaim (i.e. usage
> > goes down), but if zswap consumed a full page from the system
> > perspective, the math won't math.
> > 
> > Separate limits *could* be the answer, but it's harder to configure and
> > existing configuration won't "just work" with compressed memory.
> >
> 
> I think you are right. I am also inquiring whether individual page
> compression data is retrievable.  If so, then this actually should be a
> trivial integration.
> 
> If not then this is probably ending up on the cutting room floor and
> going straight to a full cram.c implementation.
> 
> ~Gregory