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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAKEwX=Nfu23j37GLGBXnxgb0N0Hwnk4jVneY=wTSUNQBDTgCXw@mail.gmail.com>
Date: Sun, 9 Mar 2025 15:20:53 -0700
From: Nhat Pham <nphamcs@...il.com>
To: Barry Song <21cnbao@...il.com>
Cc: Hillf Danton <hdanton@...a.com>, Qun-Wei Lin <qun-wei.lin@...iatek.com>, 
	Sergey Senozhatsky <senozhatsky@...omium.org>, linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH 2/2] kcompressd: Add Kcompressd for accelerated zram compression

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?