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

Message-ID: <CAKEwX=PNHik8O6swwRPsuDovtCNLxXRQUsiXZSSq8ZbzFvJV0w@mail.gmail.com>
Date: Mon, 10 Mar 2025 09:58:03 -0700
From: Nhat Pham <nphamcs@...il.com>
To: Qun-wei Lin (林群崴) <Qun-wei.Lin@...iatek.com>
Cc: "21cnbao@...il.com" <21cnbao@...il.com>, Andrew Yang (楊智強) <Andrew.Yang@...iatek.com>, 
	Casper Li (李中榮) <casper.li@...iatek.com>, 
	"chrisl@...nel.org" <chrisl@...nel.org>, James Hsu (徐慶薰) <James.Hsu@...iatek.com>, 
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>, 
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	"linux-mediatek@...ts.infradead.org" <linux-mediatek@...ts.infradead.org>, 
	"ira.weiny@...el.com" <ira.weiny@...el.com>, "linux-mm@...ck.org" <linux-mm@...ck.org>, 
	"dave.jiang@...el.com" <dave.jiang@...el.com>, 
	"schatzberg.dan@...il.com" <schatzberg.dan@...il.com>, 
	Chinwen Chang (張錦文) <chinwen.chang@...iatek.com>, 
	"viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>, "ryan.roberts@....com" <ryan.roberts@....com>, 
	"minchan@...nel.org" <minchan@...nel.org>, "axboe@...nel.dk" <axboe@...nel.dk>, 
	"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>, "kasong@...cent.com" <kasong@...cent.com>, 
	"nvdimm@...ts.linux.dev" <nvdimm@...ts.linux.dev>, 
	"vishal.l.verma@...el.com" <vishal.l.verma@...el.com>, 
	"matthias.bgg@...il.com" <matthias.bgg@...il.com>, 
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, 
	"senozhatsky@...omium.org" <senozhatsky@...omium.org>, 
	"dan.j.williams@...el.com" <dan.j.williams@...el.com>
Subject: Re: [PATCH 0/2] Improve Zram by separating compression context from kswapd

On Mon, Mar 10, 2025 at 6:22 AM Qun-wei Lin (林群崴)
<Qun-wei.Lin@...iatek.com> wrote:
>
>
> Thank you for your explanation. Compared to the original single kswapd,
> we expect t1 to have a slight increase in re-scan time. However, since
> our kcompressd can focus on compression tasks and we can have multiple
> kcompressd instances (kcompressd0, kcompressd1, ...) running in
> parallel, we anticipate that the number of times a folio needs be re-
> scanned will not be too many.
>
> In our experiments, we fixed the CPU and DRAM at a certain frequency.
> We created a high memory pressure enviroment using a memory eater and
> recorded the increase in pgsteal_anon per second, which was around 300,
> 000. Then we applied our patch and measured again, that pgsteal_anon/s
> increased to over 800,000.
>
> > >
> > > >
> > > > 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,
> > >
> > > What bottleneck are we talking about? Is one stage slower than the
> > > other?
> > >
> > > >  especially under high memory pressure. The kswapd thread becomes
> > > > a
> > > >  single point of contention, causing delays in memory reclaiming
> > > > and
> > > >  overall system performance degradation.
> > > >
> > > > Target:
> > > >  The target of this invention is to improve the efficiency of
> > > > memory
> > > >  reclaiming. By separating the tasks of page scanning and page
> > > >  compression into distinct processes or threads, the system can
> > > > handle
> > > >  memory pressure more effectively.
> > >
> > > I'm not a zram maintainer, so I'm definitely not trying to stop
> > > this
> > > patch. But whatever problem zram is facing will likely occur with
> > > zswap too, so I'd like to learn more :)
> >
> > Right, this is likely something that could be addressed more
> > generally
> > for zswap and zram.
> >
>
> Yes, we also hope to extend this to other swap devices, but currently,
> we have only modified zram. We are not very familiar with zswap and
> would like to ask if anyone has any suggestions for modifications?
>

My understanding is right now schedule_bio_write is the work
submission API right? We can make it generic, having it accept a
callback and a generic untyped pointer which can be casted into a
backend-specific context struct. For zram it would contain struct zram
and the bio. For zswap, depending on at which point do you want to
begin offloading the work - it could simply be just the folio itself
if we offload early, or a more complicated scheme.



> > Thanks
> > Barry
>
> Best Regards,
> Qun-wei
>
>