linux-kernel - Re: [PATCH 0/2] Improve Zram by separating compression context from kswapd

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-next>] [day] [month] [year] [list]

Message-ID: <Z9MCwXzYDRJoTiIr@google.com>
Date: Thu, 13 Mar 2025 09:07:29 -0700
From: Minchan Kim <minchan@...nel.org>
To: Barry Song <baohua@...nel.org>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>,
	Qun-Wei Lin <qun-wei.lin@...iatek.com>,
	Jens Axboe <axboe@...nel.dk>,
	Vishal Verma <vishal.l.verma@...el.com>,
	Dan Williams <dan.j.williams@...el.com>,
	Dave Jiang <dave.jiang@...el.com>, Ira Weiny <ira.weiny@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Matthias Brugger <matthias.bgg@...il.com>,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	Chris Li <chrisl@...nel.org>, Ryan Roberts <ryan.roberts@....com>,
	"Huang, Ying" <ying.huang@...el.com>,
	Kairui Song <kasong@...cent.com>,
	Dan Schatzberg <schatzberg.dan@...il.com>,
	Al Viro <viro@...iv.linux.org.uk>, linux-kernel@...r.kernel.org,
	linux-block@...r.kernel.org, nvdimm@...ts.linux.dev,
	linux-mm@...ck.org, linux-arm-kernel@...ts.infradead.org,
	linux-mediatek@...ts.infradead.org,
	Casper Li <casper.li@...iatek.com>,
	Chinwen Chang <chinwen.chang@...iatek.com>,
	Andrew Yang <andrew.yang@...iatek.com>,
	James Hsu <james.hsu@...iatek.com>
Subject: Re: [PATCH 0/2] Improve Zram by separating compression context from
 kswapd

On Thu, Mar 13, 2025 at 04:45:54PM +1300, Barry Song wrote:
> On Thu, Mar 13, 2025 at 4:09 PM Sergey Senozhatsky
> <senozhatsky@...omium.org> wrote:
> >
> > On (25/03/12 11:11), Minchan Kim wrote:
> > > On Fri, Mar 07, 2025 at 08:01:02PM +0800, Qun-Wei Lin wrote:
> > > > This patch series introduces a new mechanism called kcompressd to
> > > > improve the efficiency of memory reclaiming in the operating system. The
> > > > main goal is to separate the tasks of page scanning and page compression
> > > > into distinct processes or threads, thereby reducing the load on the
> > > > kswapd thread and enhancing overall system performance under high memory
> > > > pressure conditions.
> > > >
> > > > Problem:
> > > >  In the current system, the kswapd thread is responsible for both
> > > >  scanning the LRU pages and compressing pages into the ZRAM. This
> > > >  combined responsibility can lead to significant performance bottlenecks,
> > > >  especially under high memory pressure. The kswapd thread becomes a
> > > >  single point of contention, causing delays in memory reclaiming and
> > > >  overall system performance degradation.
> > >
> > > Isn't it general problem if backend for swap is slow(but synchronous)?
> > > I think zram need to support asynchrnous IO(can do introduce multiple
> > > threads to compress batched pages) and doesn't declare it's
> > > synchrnous device for the case.
> >
> > The current conclusion is that kcompressd will sit above zram,
> > because zram is not the only compressing swap backend we have.

Then, how handles the file IO case?

> 
> also. it is not good to hack zram to be aware of if it is kswapd
> , direct reclaim , proactive reclaim and block device with
> mounted filesystem.

Why shouldn't zram be aware of that instead of just introducing
queues in the zram with multiple compression threads?

> 
> so i am thinking sth as below
> 
> page_io.c
> 
> if (sync_device or zswap_enabled())
>    schedule swap_writepage to a separate per-node thread

I am not sure that's a good idea to mix a feature to solve different
layers. That wouldn't be only swap problem. Such an parallelism under
device  is common technique these days and it would help file IO cases.

Furthermore, it would open the chance for zram to try compress
multiple pages at once.