Message-ID: <20260113162452.00000da9@huawei.com>
Date: Tue, 13 Jan 2026 16:24:52 +0000
From: Jonathan Cameron <jonathan.cameron@...wei.com>
To: Gregory Price <gourry@...rry.net>
CC: Yosry Ahmed <yosry.ahmed@...ux.dev>, <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>,
	<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


...

> > Are we checking if the device has enough memory for the worst case
> > scenario (i.e. PAGE_SIZE)?
> > 
> > Or are we checking if the device can compress this specific page and
> > checking if it can compress it and store it? This seems like it could be
> > racy and there might be some throwaway work.
> >   
> 
> We essentially need to capture the current compression ratio and
> real-usage to determine whether there's another page available.
> 
> It is definitely racey, and the best we can do is set reasonable
> real-memory-usage limits to prevent ever finding ourselves in that
> scenario.  That most likely means requiring the hardware send an
> interrupt when usage and/or ratio hit some threshhold and setting a
> "NO ALLOCATION ALLOWED" bit.

I believe we could do some dance to close the race.

What we need is some upper bounds on usage at any point in time,
if that estimate is too high stop allocating until we get a better bound.

Can do that by starting an allocation counter before reading capacity.
As long as it only counts allocations (and not frees) then it will
always be an upper bound. 

Any frees will be dealt with when we reread current allocation (having
started a new counter of allocations just before that). Once we have
that new upper bound, can ignore the previous one as being less accurate.

If we see the interrupt, all bets are off. That's a fatal error in capacity
tracking.

> 
> But in software we can also try to query/track this as well, but we may
> not be able to query the device at allocation time (or at least that
> would be horribly non-performant).
> 
> So yeah, it's racy.

 
> > > 
> > > Thank you again for taking a look, this has been enlightening.  Good
> > > takeaways for the rest of the N_PRIVATE design.  
> > 
> > Thanks for kicking off the discussion here, an interesting problem to
> > solve for sure :)
> >   
> 
> One of the more interesting ones i've had in a few years :]

Agreed. Compressed memory is fun ;)
> 
> Cheers,
> ~Gregory

Powered by blists - more mailing lists