Re: [PATCH v5 00/21] Virtual Swap Space

[Kairui Song]

On Sat, Apr 25, 2026 at 1:28 AM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
>
> On Thu, Apr 23, 2026 at 9:16 PM Kairui Song <ryncsn@xxxxxxxxx> wrote:
>
> My apologies for delayed response - I'm cleaning things up, and
> fighting with some memsw issue. I changed the semantic of the
> memory.swap counter a bit, but that makes it diverge operationally
> from memsw. Need to be careful not double charging or double
> uncharging here.

Hi Nhat,

No worries.

About memory.swap, I also thought about changing it a bit previously
to make thing cleaner:
https://lore.kernel.org/linux-mm/20260220-swap-table-p4-v1-7-104795d19815@xxxxxxxxxxx/

But I dropped that part so swap table series p4 can be reviewed
without any behavior change. Not sure if related.

> > I think it's actually functionally very similar to Nhat's design
> > already from a high level, the only difference is we don't need
> > standalone infra for virtual parts.
> Well yeah, great minds think alike ;)

:)

>
> As you have noticed, I have also converged towards a lot of your
> metadata design and operational arrangement.
>
> Case in point is the delaying of cgroup check merging with swap
> freeing - I did not notice that patch you had in your series, but I
> realized I had to do it as well after studying the regression for
> awhile.
>
> (I did think about proposing that outside of the vswap series, but I
> was thinking it would not be a problem at all with the current code.
> But in hindsight, since you're also merging swap cgroup with swap
> table, it will have a similar implications, albeit less expensive due
> to no xarray indirection).

There are actually more issues behind that. Later we would also want
to distinguish shmem / anon swap entries again, so swap cache
allocation ensures there is no conflict between these two. That is
also causing some real issues.

>
> Hopefully we can iron out the rest of the differences. I have a couple

Yeah, definitely. I think things are already getting much cleaner as
we keep unifying and simplify the swap infra. Consider the current
swap file something like s swap mapping as an infra seems to make
things easier to understand as well.

> more use cases in mind (compressed writeback from zswap, discontiguous
> fallback for swapout, etc.), but without virtualization they seem like
> a deadend :(
>
> And Gregory's cram stuff too - I think it's not undoable without
> vswap, but it's just a lot hairier :(

Ah, I'm not against a virtual layer at all, actually that's a shared
goal, I mean we might not want something mandatory, and redo
everything again with more overhead.