From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: Gregory Price <gourry@gourry.net>
Cc: Yosry Ahmed <yosry.ahmed@linux.dev>, <linux-mm@kvack.org>,
<cgroups@vger.kernel.org>, <linux-cxl@vger.kernel.org>,
<linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-fsdevel@vger.kernel.org>, <kernel-team@meta.com>,
<longman@redhat.com>, <tj@kernel.org>, <hannes@cmpxchg.org>,
<mkoutny@suse.com>, <corbet@lwn.net>,
<gregkh@linuxfoundation.org>, <rafael@kernel.org>,
<dakr@kernel.org>, <dave@stgolabs.net>, <dave.jiang@intel.com>,
<alison.schofield@intel.com>, <vishal.l.verma@intel.com>,
<ira.weiny@intel.com>, <dan.j.williams@intel.com>,
<akpm@linux-foundation.org>, <vbabka@suse.cz>,
<surenb@google.com>, <mhocko@suse.com>, <jackmanb@google.com>,
<ziy@nvidia.com>, <david@kernel.org>,
<lorenzo.stoakes@oracle.com>, <Liam.Howlett@oracle.com>,
<rppt@kernel.org>, <axelrasmussen@google.com>,
<yuanchu@google.com>, <weixugc@google.com>,
<yury.norov@gmail.com>, <linux@rasmusvillemoes.dk>,
<rientjes@google.com>, <shakeel.butt@linux.dev>,
<chrisl@kernel.org>, <kasong@tencent.com>,
<shikemeng@huaweicloud.com>, <nphamcs@gmail.com>,
<bhe@redhat.com>, <baohua@kernel.org>, <chengming.zhou@linux.dev>,
<roman.gushchin@linux.dev>, <muchun.song@linux.dev>,
<osalvador@suse.de>, <matthew.brost@intel.com>,
<joshua.hahnjy@gmail.com>, <rakie.kim@sk.com>, <byungchul@sk.com>,
<ying.huang@linux.alibaba.com>, <apopple@nvidia.com>,
<cl@gentwo.org>, <harry.yoo@oracle.com>,
<zhengqi.arch@bytedance.com>
Subject: Re: [RFC PATCH v3 7/8] mm/zswap: compressed ram direct integration
Date: Tue, 13 Jan 2026 16:24:52 +0000 [thread overview]
Message-ID: <20260113162452.00000da9@huawei.com> (raw)
In-Reply-To: <aWWEvAaUmpA_0ERP@gourry-fedora-PF4VCD3F>
...
> > 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
next prev parent reply other threads:[~2026-01-13 16:25 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-08 20:37 [RFC PATCH v3 0/8] mm,numa: N_PRIVATE node isolation for device-managed memory Gregory Price
2026-01-08 20:37 ` [RFC PATCH v3 1/8] numa,memory_hotplug: create N_PRIVATE (Private Nodes) Gregory Price
2026-01-08 20:37 ` [RFC PATCH v3 2/8] mm: constify oom_control, scan_control, and alloc_context nodemask Gregory Price
2026-01-08 20:37 ` [RFC PATCH v3 3/8] mm: restrict slub, compaction, and page_alloc to sysram Gregory Price
2026-01-08 20:37 ` [RFC PATCH v3 4/8] cpuset: introduce cpuset.mems.sysram Gregory Price
2026-01-12 17:56 ` Yury Norov
2026-01-08 20:37 ` [RFC PATCH v3 5/8] Documentation/admin-guide/cgroups: update docs for mems_allowed Gregory Price
2026-01-12 14:30 ` Michal Koutný
2026-01-12 15:25 ` Gregory Price
2026-01-08 20:37 ` [RFC PATCH v3 6/8] drivers/cxl/core/region: add private_region Gregory Price
2026-01-08 20:37 ` [RFC PATCH v3 7/8] mm/zswap: compressed ram direct integration Gregory Price
2026-01-09 16:00 ` Yosry Ahmed
2026-01-09 17:03 ` Gregory Price
2026-01-09 21:40 ` Gregory Price
2026-01-12 21:13 ` Yosry Ahmed
2026-01-12 23:33 ` Gregory Price
2026-01-12 23:46 ` Gregory Price
2026-01-13 16:24 ` Jonathan Cameron [this message]
2026-01-13 7:35 ` Nhat Pham
2026-01-13 7:49 ` Nhat Pham
2026-01-08 20:37 ` [RFC PATCH v3 8/8] drivers/cxl: add zswap private_region type Gregory Price
2026-01-12 11:12 ` [RFC PATCH v3 0/8] mm,numa: N_PRIVATE node isolation for device-managed memory Balbir Singh
2026-01-12 14:36 ` Gregory Price
2026-01-12 17:18 ` Yury Norov
2026-01-12 17:36 ` Gregory Price
2026-01-12 21:24 ` dan.j.williams
2026-01-12 21:57 ` Balbir Singh
2026-01-12 22:10 ` dan.j.williams
2026-01-12 22:54 ` Balbir Singh
2026-01-12 23:40 ` Gregory Price
2026-01-13 1:12 ` Balbir Singh
2026-01-13 1:17 ` dan.j.williams
2026-01-13 2:30 ` Gregory Price
2026-01-13 3:12 ` dan.j.williams
2026-01-13 14:15 ` Gregory Price
2026-01-13 3:24 ` Balbir Singh
2026-01-13 14:21 ` Gregory Price
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=20260113162452.00000da9@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=alison.schofield@intel.com \
--cc=apopple@nvidia.com \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=bhe@redhat.com \
--cc=byungchul@sk.com \
--cc=cgroups@vger.kernel.org \
--cc=chengming.zhou@linux.dev \
--cc=chrisl@kernel.org \
--cc=cl@gentwo.org \
--cc=corbet@lwn.net \
--cc=dakr@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=david@kernel.org \
--cc=gourry@gourry.net \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=harry.yoo@oracle.com \
--cc=ira.weiny@intel.com \
--cc=jackmanb@google.com \
--cc=joshua.hahnjy@gmail.com \
--cc=kasong@tencent.com \
--cc=kernel-team@meta.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@rasmusvillemoes.dk \
--cc=longman@redhat.com \
--cc=lorenzo.stoakes@oracle.com \
--cc=matthew.brost@intel.com \
--cc=mhocko@suse.com \
--cc=mkoutny@suse.com \
--cc=muchun.song@linux.dev \
--cc=nphamcs@gmail.com \
--cc=osalvador@suse.de \
--cc=rafael@kernel.org \
--cc=rakie.kim@sk.com \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=rppt@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=shikemeng@huaweicloud.com \
--cc=surenb@google.com \
--cc=tj@kernel.org \
--cc=vbabka@suse.cz \
--cc=vishal.l.verma@intel.com \
--cc=weixugc@google.com \
--cc=ying.huang@linux.alibaba.com \
--cc=yosry.ahmed@linux.dev \
--cc=yuanchu@google.com \
--cc=yury.norov@gmail.com \
--cc=zhengqi.arch@bytedance.com \
--cc=ziy@nvidia.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