Re: [PATCH v5 4/4] mm: Introduce per-thpsize swapin control policy

[Nhat Pham <nphamcs@gmail.com>]

On Tue, Jul 30, 2024 at 9:30 AM Christoph Hellwig <hch@infradead.org> wrote:
>
>
> Well, that is the point.  zram is a horrible hack that abuses a block
> device to implement a feature missing the VM layer.  Right now people
> have a reason for it because zswap requires a "real" backing device
> and that's fine for them and for now.  But instead of building VM

I completely agree with this assessment.

> infrastructure around these kinds of hacks we need to fix the VM
> infrastructure.  Chris Li has been talking about and working towards
> a proper swap abstraction and that needs to happen.

I'm also working towards something along this line. My design would
add a "virtual" swap ID that will be stored in the page table, and can
refer to either a real, storage-backed swap entry, or a zswap entry.
zswap can then exist without any backing swap device.

There are several additional benefits of this approach:

1. We can optimize swapoff as well - the page table can still refer to
the swap ID, but the ID now points to a physical page frame. swapoff
code just needs to sever the link from the swap ID to the physical
swap entry (which either just requires a swap ID mapping walk, or even
faster if we have a reverse mapping mechanism), and update the link to
the page frame instead.

2. We can take this opportunity to clean up the swap count code.

I'd be happy to collaborate/compare notes :)