Re: [RFC PATCH v2 0/4] mm/swap: reserve swap areas for deliberate offload

[Andy Lutomirski]

> On Sep 25, 2026, at 9:55 PM, Matthias Goergens <matthias.goergens@xxxxxxxxx> 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.