linux-kernel - Re: [PATCH 0/8] make unregistration of super

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]

Date:   Wed, 31 May 2023 11:40:54 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Qi Zheng <qi.zheng@...ux.dev>
Cc:     tkhai@...ru, roman.gushchin@...ux.dev, vbabka@...e.cz,
        viro@...iv.linux.org.uk, brauner@...nel.org, djwong@...nel.org,
        hughd@...gle.com, paulmck@...nel.org, muchun.song@...ux.dev,
        linux-mm@...ck.org, linux-fsdevel@...r.kernel.org,
        linux-xfs@...r.kernel.org, linux-kernel@...r.kernel.org,
        Qi Zheng <zhengqi.arch@...edance.com>
Subject: Re: [PATCH 0/8] make unregistration of super_block shrinker more
 faster

On Wed, 31 May 2023 09:57:34 +0000 Qi Zheng <qi.zheng@...ux.dev> wrote:

> From: Qi Zheng <zhengqi.arch@...edance.com>
> 
> Hi all,
> 
> This patch series aims to make unregistration of super_block shrinker more
> faster.
> 
> 1. Background
> =============
> 
> The kernel test robot noticed a -88.8% regression of stress-ng.ramfs.ops_per_sec
> on commit f95bdb700bc6 ("mm: vmscan: make global slab shrink lockless"). More
> details can be seen from the link[1] below.
> 
> [1]. https://lore.kernel.org/lkml/202305230837.db2c233f-yujie.liu@intel.com/
> 
> We can just use the following command to reproduce the result:
> 
> stress-ng --timeout 60 --times --verify --metrics-brief --ramfs 9 &
> 
> 1) before commit f95bdb700bc6b:
> 
> stress-ng: info:  [11023] dispatching hogs: 9 ramfs
> stress-ng: info:  [11023] stressor       bogo ops real time  usr time  sys time   bogo ops/s     bogo ops/s
> stress-ng: info:  [11023]                           (secs)    (secs)    (secs)   (real time) (usr+sys time)
> stress-ng: info:  [11023] ramfs            774966     60.00     10.18    169.45     12915.89        4314.26
> stress-ng: info:  [11023] for a 60.00s run time:
> stress-ng: info:  [11023]    1920.11s available CPU time
> stress-ng: info:  [11023]      10.18s user time   (  0.53%)
> stress-ng: info:  [11023]     169.44s system time (  8.82%)
> stress-ng: info:  [11023]     179.62s total time  (  9.35%)
> stress-ng: info:  [11023] load average: 8.99 2.69 0.93
> stress-ng: info:  [11023] successful run completed in 60.00s (1 min, 0.00 secs)
> 
> 2) after commit f95bdb700bc6b:
> 
> stress-ng: info:  [37676] dispatching hogs: 9 ramfs
> stress-ng: info:  [37676] stressor       bogo ops real time  usrtime  sys time   bogo ops/s     bogo ops/s
> stress-ng: info:  [37676]                           (secs)    (secs)   (secs)   (real time) (usr+sys time)
> stress-ng: info:  [37676] ramfs            168673     60.00     1.61    39.66      2811.08        4087.47
> stress-ng: info:  [37676] for a 60.10s run time:
> stress-ng: info:  [37676]    1923.36s available CPU time
> stress-ng: info:  [37676]       1.60s user time   (  0.08%)
> stress-ng: info:  [37676]      39.66s system time (  2.06%)
> stress-ng: info:  [37676]      41.26s total time  (  2.15%)
> stress-ng: info:  [37676] load average: 7.69 3.63 2.36
> stress-ng: info:  [37676] successful run completed in 60.10s (1 min, 0.10 secs)

Is this comparison reversed?  It appears to demonstrate that
f95bdb700bc6b made the operation faster.