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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACePvbV9DZJcYL17MyYrEjRehqfj1LQtj3TwrKuP913NAP4sZA@mail.gmail.com>
Date: Thu, 1 Aug 2024 13:55:51 -0700
From: Chris Li <chrisl@...nel.org>
To: Christoph Hellwig <hch@...radead.org>
Cc: Barry Song <21cnbao@...il.com>, Matthew Wilcox <willy@...radead.org>, akpm@...ux-foundation.org, 
	linux-mm@...ck.org, ying.huang@...el.com, baolin.wang@...ux.alibaba.com, 
	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, nphamcs@...il.com, 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 Tue, Jul 30, 2024 at 9:30 AM Christoph Hellwig <hch@...radead.org> wrote:
>
> On Tue, Jul 30, 2024 at 08:11:16AM +1200, Barry Song wrote:
> > > We also really need to stop optimizing for this weird zram case and move
> > > people to zswap instead after fixing the various issues.  A special
> > > block device that isn't really a block device and needs various special
> > > hooks isn't the right abstraction for different zwap strategies.
> >
> > My understanding is zRAM is much more popularly used in embedded
> > systems than zswap. I seldomly(or never) hear who is using zswap
> > in Android. it seems pointless to force people to move to zswap, in
> > embedded systems we don't have a backend real block disk device
> > after zswap.
>
> 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
> 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.

Yes, I have been working on the swap allocator for the mTHP usage
case. Haven't got to the zswap vs zram yet.
Currently there is a feature gap between zswap and zram, so zswap
doesn't do all the stuff zram does. For the zswap "real" backend
issue, Google has been using the ghost swapfile for many years. That
can be one way to get around that. The patch is much smaller than
overhauling the swap back end abstraction.

Currently Android uses zram and it needs to be the Android team's
decision to move from zram to something else. I don't see that
happening any time soon. There are practical limitations.
Personally I have been using zram as some way to provide a block like
device as my goto route for testing the swap stack. I still do an SSD
drive swap test, but at the same time I want to reduce the SSD swap
usage to avoid the wear on my SSD drive. I already destroyed two of my
old HDD drives during the swap testing. The swap random seek is very
unfriendly to HDD, not sure who is still using HDD for swap any more.

Anyway, removing zram is never a goal of the swap abstraction because
I am still using it. We can start with reducing the feature gap
between zswap and ZRAM. The end of the day, it is the Android team's
call using zram or not.

Chris