linux-kernel - Re: [linus:master] [mm, swap] 7277433096: swapin.throughput 33.0% regression

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: <CAMgjq7AHR9zg+-BRhMeE_06endOP1dno0=rKZjU2CUmUzbh0ow@mail.gmail.com>
Date: Thu, 24 Apr 2025 17:38:41 +0800
From: Kairui Song <ryncsn@...il.com>
To: kernel test robot <oliver.sang@...el.com>
Cc: oe-lkp@...ts.linux.dev, lkp@...el.com, linux-kernel@...r.kernel.org, 
	Andrew Morton <akpm@...ux-foundation.org>, Chris Li <chrisl@...nel.org>, 
	"Huang, Ying" <ying.huang@...ux.alibaba.com>, Baoquan He <bhe@...hat.com>, 
	Barry Song <v-songbaohua@...o.com>, Hugh Dickens <hughd@...gle.com>, 
	Johannes Weiner <hannes@...xchg.org>, Kalesh Singh <kaleshsingh@...gle.com>, 
	Nhat Pham <nphamcs@...il.com>, Ryan Roberts <ryan.roberts@....com>, 
	Yosry Ahmed <yosryahmed@...gle.com>, linux-mm@...ck.org
Subject: Re: [linus:master] [mm, swap] 7277433096: swapin.throughput 33.0% regression

On Thu, Apr 24, 2025 at 4:40 PM kernel test robot <oliver.sang@...el.com> wrote:
>
>
>
> Hello,
>
>
> note:
> from commit message, this regression should be expected. we still make out this
> report FYI what's the possible impact of this change.
>
> below details just FYI.

Hi,

For most workloads with random swap io, there shouldn't be any
regression. I checked the test and it's doing a sequential swapout
with 8 workers (after a fresh swapon?). I was expecting
bae8a4ef3efb56bb7e83bafd3c0856845aeaf605 ("mm, swap: use a global swap
cluster for non-rotation devices") to optimize it. Seems that's not
enough?

I guess we might also need to disable the cluster shuffle in
setup_clusters for HDD. The shuffle was meant to reduce lock
contention on swap cache, the contention is clearly not an issue for
HDD, the bottleneck for this test is IO, that might be making the IO
more randomized. Or maybe clusters will better be sorted by offset for
HDD.

It seems this test can be easily reproduced with `$USEMEM -n $nr_task
-W -d -p $TMP/pidfile $((size / nr_task))`, I think it's not a real
problem in productions, but I'll try fix this if have time.