linux-kernel - Re: [PATCH 2/2] kcompressd: Add Kcompressd for accelerated zram compression

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 for Android: free password hash cracker in your pocket

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

Message-ID: <103fe85acd46fcb099a81e435d4cee2826d0357b.camel@mediatek.com>
Date: Mon, 10 Mar 2025 13:23:11 +0000
From: Qun-wei Lin (林群崴) <Qun-wei.Lin@...iatek.com>
To: "21cnbao@...il.com" <21cnbao@...il.com>, "nphamcs@...il.com"
	<nphamcs@...il.com>
CC: "hdanton@...a.com" <hdanton@...a.com>, "senozhatsky@...omium.org"
	<senozhatsky@...omium.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH 2/2] kcompressd: Add Kcompressd for accelerated zram
 compression

On Sun, 2025-03-09 at 15:20 -0700, Nhat Pham wrote:
> 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> 
> 
> On Sun, Mar 9, 2025 at 1:44 PM Barry Song <21cnbao@...il.com> wrote:
> > 
> > On Mon, Mar 10, 2025 at 8:56 AM Nhat Pham <nphamcs@...il.com>
> > wrote:
> > > 
> > > On Sat, Mar 8, 2025 at 5:05 PM Hillf Danton <hdanton@...a.com>
> > > wrote:
> > > > 
> > > > Could you explain what nr_kcompressd means, Qun-Wei, to quiesce
> > > > barking lads?
> > > 
> > > Who's the "barking lads" you are referring to? Please mind your
> > > language.
> > 
> > I also feel extremely uncomfortable. In Eastern culture, this is an
> > extremely
> > vulgar word, more offensive than any others.
> > 
> > I strongly feel that this violates the mutual respect within the
> > Linux
> > community. This is a serious case of verbal abuse.
> > 
> > Regardless of the existence of nr_kcompressd, it is still
> > unacceptable to
> > invent an interface that requires users to figure out how to set it
> > up, while
> > kswapd can launch threads based on NUMA nodes.
> > This should be transparent to users, just as kswapd does.
> > 
> > void __meminit kswapd_run(int nid)
> > 
> > {
> >         ...
> >         if (!pgdat->kswapd) {
> >                 pgdat->kswapd = kthread_create_on_node(kswapd,
> > pgdat,
> > nid, "kswapd%d", nid);
> >                 ...
> >         }
> >         pgdat_kswapd_unlock(pgdat);
> > }
> > 
> > On the other hand, no one will know how to set up the proper number
> > of
> > threads, while direct reclaim can utilize each CPU.
> 
> Agree - how are users supposed to set this? The default puzzles me
> too. Why 4? Does it work across architectures? Across workloads?
> 
> This makes no sense to me. Can we scale the number of threads in
> proportion to the number of CPUs? Per-cpu kcompressd?

The default value is actually designed to be the maximum number of
kcompressd that can run simultaneously. The current design is to create
the next kcompressd thread when all kfifos are full, and the number 4
is just a temporary setting. 

You are right, changing it to match the number of CPUs might be better
to avoid confusion on how to set it up.


Best Regards,
Qun-wei