Re: [LSF/MM/BPF TOPIC][RFC PATCH v4 00/27] Private Memory Nodes (w/ Compressed RAM)

[Arun George/Arun George <arun.george@samsung.com>]

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?

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.

But that approach will not give a generic solution and not available for 
user-land anyway!
>> And I believe the bear-proof cage might work in the normal scenarios,
>> but may not work for all.
> 
> If it can't work for all workloads, then it's likely not general purpose
> enough to find core kernel support and should seek to use the existing
> interfaces (DAX and friends).
> 
I agree. That is a good point.

> 
> You need two controls over compressed RAM for it to be reliable:
> 
>    - Allocation control (acquiring new struct page to write to)
>    - Write-control (preventing new writes to compressed pages)
> 
> Private nodes provide the allocation control.
> 
> A read-only mapping, and guarantee that only memory that can reach
> the device is userland memory - is the only way to control the cpu
> writes from the OS perspective.
> 
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.)>
> In the next version of the RFC i'll demonstrate cram.c as a new swap
> backend that allows for read-only mappings to be soft-faulted in,
> migration on write, isolation to ANON memory, and some optional
> settings that allow a device or administrator a "writable budget"
> which allows some number of pages to be made writable without migration.

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?>
> ~Gregory
> 
~Arun George