Message-ID: <CAGsJ_4z1koYbroafQEUm0Sbm3QM2Ag11huUMKA6REQM_bWgRng@mail.gmail.com>
Date: Wed, 31 Jul 2024 09:06:17 +1200
From: Barry Song <21cnbao@...il.com>
To: Nhat Pham <nphamcs@...il.com>
Cc: Christoph Hellwig <hch@...radead.org>, Matthew Wilcox <willy@...radead.org>, akpm@...ux-foundation.org, 
	linux-mm@...ck.org, ying.huang@...el.com, baolin.wang@...ux.alibaba.com, 
	chrisl@...nel.org, david@...hat.com, hannes@...xchg.org, hughd@...gle.com, 
	kaleshsingh@...gle.com, kasong@...cent.com, linux-kernel@...r.kernel.org, 
	mhocko@...e.com, minchan@...nel.org, ryan.roberts@....com, 
	senozhatsky@...omium.org, shakeel.butt@...ux.dev, shy828301@...il.com, 
	surenb@...gle.com, v-songbaohua@...o.com, xiang@...nel.org, 
	yosryahmed@...gle.com
Subject: Re: [PATCH v5 4/4] mm: Introduce per-thpsize swapin control policy

On Wed, Jul 31, 2024 at 7:28 AM Nhat Pham <nphamcs@...il.com> wrote:
>
> On Tue, Jul 30, 2024 at 9:30 AM Christoph Hellwig <hch@...radead.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 :)

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?

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

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 don't see any reason why we should wait and not start implementing something
that could benefit billions of devices worldwide. Parallel exploration leads to
human progress in different fields. That's why I believe Yosry's patch, which
allows others to move forward, is a more considerate approach.

Thanks
Barry

Powered by blists - more mailing lists