On Wed, Apr 29, 2026 at 11:45:26AM +0530, Arun George/Arun George wrote:
> On 28-04-2026 03:58 am, Gregory Price wrote:
> > On Mon, Apr 27, 2026 at 06:02:57PM +0530, Arun George wrote:
> >>
> >> Any particular workload you are targeting with
> >> this (which can tolerate this latency)?
> >>
> >> Any deployments you think of where the goal is a capacity expansion
> >> with a compromise in performance?
> >>
> > Primary use cases for us are any workload that benefits from zswap -
> > which is many, many (many, many [many, many]) workloads.
> >
> A curious question please. If the primary use case is swap, can't we
> handle this problem statement by re-using the zsmalloc allocation classes?
>
I'm using swap semantics for allocation ("demote + leafent") but otherwise
on-fault rather than removing the swap-entry, we leave it cached and
replace the page table entry with a read-only mapping (if Read-fault).
If there's a writable budget, and the node is under that budget, we may
also allow upgrading the read-only page to be writable (at which point
we would reap the swap entry).
This requires careful reverse-mapping in case there are multiple mappers
of the same folio.
Since otherwise the allocation is just alloc_pages_node(), and the fault
patterns differ from typical swap - i didn't see the need to overcomplicate
things by cramming the logic into zswap/zsmalloc instead of just making
it its own vswap[1] backend that sits in front of zswap.
vswap makes it easy to writeback a cram page to swap in the case where
the device is over-pressured and we need to make room (close the node,
disallow new cram entries, writeback existing cram entries to swap).
[1] vswap: https://lore.kernel.org/linux-mm/?t=20260320192741
> A separate size class can be reserved for non-compressed pages in
> zsmalloc. And this interface could be used by zswap, zram etc. (We have
> been using this implementation for testing btw.). This does not require
> additional book-keeping or buddy allocator.
>
The other reason not to overload an existing mechanism is because these
devices (that i've seen) cannot provide per-page compressability stats,
and so it would end up just looking like a bunch of either
uncompressible capacity or unknown compressed capacity.
That makes it harder for those components to reason about what to do
with their normal software-compressed capacity (for which they do have
that data).
> So write-control part need to handled in the specific back end driver of
> private pages while the allocation control is a generic front-end sort
> of, right? (Ex: zswap cram back end for compressed devices case.)
write control is handled by the OS in three ways:
1) No file memory (no page cache)
We get this for free using the swap semantics
This prevents buffered i/o from bypassing page table controls
2) User allocations only (or at least swap-eligible only)
This prevents catestrophic system failure if the device fails
3) Page table mapping control (disallow direct writes)
This prevents uncontended writes to compressed memory by the cpu
allocation control is handled via private nodes - the driver which
hotplugs the private nodes hands that node to cram - and cram is now
aware of that capacity and will use __GFP_PRIVATE to allocate from that
node. Removal of the private node from the fallback zonelist and the
lack of __GFP_PRIVATE in all other paths prevent normal buddy allocator
users from accessing that memory.
>
> Great! I believe "writable budget" could be an interesting idea which
> can solve the 'bus error' sort of scenarios due to device not capable of
> taking any more writes. The write budget could be replenished using the
> control path and writes will not go ahead without the budget available,
> right?>
>
Write budget is simple
budget=1 (up to 1 page can be writable
1) swap 1 page -> cram alloc 1 page, put VSWAP_CRAM in PTE
2) read-fault -> cram upgrades VSWAP_CRAM to R/O PTE
3) write-fault ->
a) if (writable_cnt < budget) { budget++; mkwrite(pte); }
b) else: normal swap semantic -> promote to normal memory
The catch with the writable budget is we may not always be able to catch
all frees of the vswap pages - meaning we get zombie pages in the vswap
tables. But this is ok if we run a regular kthread scan the vswap entry
list to reap zombies.
This also gives us a great place to TRIM/FLUSH those pages to release
the capacity without zeroing them.
Meanwhile - use ballooning and a simple shrinker to dynamically size the
region to respond to real compression ratio.
All said an done - you get something close to zswap but with R/O
mappings for all entries, and optional R/W-mappings for administrators
who know something about their workload and can afford to take the risk
of some amount of capacity being written to uncontended in exchange for
performance.
The writable-budget is a risk-dial: How much do you trust your workload
to now spew un/poorly-compressible memory? The write-budget is a direct
measure of that. (so take P99.99999 compression ratios, and you can make
a good chunk of that writable).
~Gregory
