> On Sep 25, 2026, at 9:55 PM, Matthias Goergens <[email protected]>
> wrote:
>
> This RFC adds offload-only swap areas for deliberate cold-page offload to
> backends unsuitable for pressure reclaim. ZFS zvol swap has documented
> deadlocks under memory pressure [3]; compressed swap is another target
> because writes may need memory despite free logical slots.
This seems unnecessarily annoying to configure. It seems to me that you’re
creating a bizarrely named administrative flag that means, roughly, “swapping
to this location may allocate memory”. Why can’t the kernel figure this out
itself?
For that matter, how well does this even work in practice? If I configure two
swap devices, one “offload-only” and one conventional, it seems like the
relative fullness of the devices will be mostly an accident of what triggers
swap as the system is running. If the conventional swap fills up, is there a
means to proactively empty it? Under OOM conditions, will anything
preferentially kill tasks that reference memory in conventional swap?
Is the locking and recursion structure of the mm code such that we won’t have
deadlocks where cgroup triggers swap to an “offload-only” device, which
allocates, which causes memory pressure, which then tries to swap more to
conventional swap? (Maybe this works fine.)
For that matter, if the system is under overall memory pressure, why do you
care what triggered the particular swap operation that is being processed?
The remainder of the writeup is IMO somewhat incoherent. To the extent that AI
was used, can you read it and make sure it makes sense?
And the first few hundred lines of patch I skimmed seem like incomprehensible
churn. Adding “eligible” to a bunch of calls does nothing to explain what’s
going on.
