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

[Nhat Pham <nphamcs@gmail.com>]

On Tue, Jul 30, 2024 at 2:06 PM Barry Song <21cnbao@gmail.com> wrote:
>
> > I'd be happy to collaborate/compare notes :)
>
> I appreciate that you have a good plan, and I welcome the improvements in zswap.
> However, we need to face reality. Having a good plan doesn't mean we should
> wait for you to proceed.
>
> In my experience, I've never heard of anyone using zswap in an embedded
> system, especially among the billions of Android devices.(Correct me if you
> know one.) How soon do you expect embedded systems and Android to adopt
> zswap? In one year, two years, five years, or ten years? Have you asked if
> Google plans to use zswap in Android?

Well, no one uses zswap in an embedded environment precisely because
of the aforementioned issues, which we are working to resolve :)

>
> Currently, zswap does not support large folios, which is why Yosry has
> introduced
> an API like zswap_never_enabled() to allow others to explore parallel
> options like
> mTHP swap. Meanwhile, If zswap encounters large folios, it will trigger a SIGBUS
> error.  I believe you were involved in those discussions:
>
> mm: zswap: add zswap_never_enabled()
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2d4d2b1cfb85cc07f6
> mm: zswap: handle incorrect attempts to load large folios
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c63f210d4891f5b1
>

I am, and for the record I reviewed and/or ack-ed all of these
patches, and provided my inputs on how to move forward with zswap's
support for large folios. I do not want zswap to prevent the
development of the rest of the swap ecosystem.

> Should everyone around the world hold off on working on mTHP swap until
> zswap has addressed the issue to support large folios? Not to mention whether
> people are ready and happy to switch to zswap.
>

I think you misunderstood my intention. For the record, I'm not trying
to stop you from improving zram, and I'm not proposing that we kill
zram right away. Well, at least not until zswap reaches feature parity
with zram, which, as you point out, will take awhile. Both support for
large folios and swap/zswap decoupling are on our agenda, and you're
welcome to participate in the discussion - for what it's worth, your
attempt with zram (+zstd) is the basis/proof-of-concept for our future
efforts :)

That said, I believe that there is a fundamental redundancy here,
which we (zram and zswap developers) should resolve at some point by
unifying the two memory compression systems. The sooner we can unify
these two, the less effort we will have to spend on developing and
maintaining two separate mechanisms for the same (or very similar)
purpose. For instance, large folio support has to be done twice. Same
goes with writeback/offloading to backend storage, etc. And I
(admittedly with a bias), agree with Christoph that zswap is the way
to go moving forwards.

I will not address the rest - seems like there isn't something to
disagree or discuss down there :)