linux-kernel - [linus:master] [swap_state] 5649d113ff: vm-scalability.throughput -33.1% 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] [thread-next>] [day] [month] [year] [list]

Message-Id: <20230320124100.25297-1-yang.yang29@zte.com.cn>
Date:   Mon, 20 Mar 2023 12:41:00 +0000
From:   Yang Yang <yang.yang29@....com.cn>
To:     yujie.liu@...el.com
Cc:     akpm@...ux-foundation.org, bagasdotme@...il.com,
        feng.tang@...el.com, fengwei.yin@...el.com, hannes@...xchg.org,
        iamjoonsoo.kim@....com, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org, lkp@...el.com,
        oe-lkp@...ts.linux.dev, ran.xiaokai@....com.cn,
        willy@...radead.org, yang.yang29@....com.cn, ying.huang@...el.com,
        zhengjun.xing@...ux.intel.com
Subject: [linus:master] [swap_state] 5649d113ff: vm-scalability.throughput -33.1% regression

> 04bac040bc71b4b3 5649d113ffce9f532a9ecc5ab96 
> ---------------- --------------------------- 
>          %stddev     %change         %stddev
>              \          |                \  
>  10026093 ±  3%     -33.1%    6702748 ±  2%  vm-scalability.throughput

I try to reproduce this and see vm-scalability.throughput really decrease.
And I use ftrace found that functions related to this patch
add_to_swap_cache()/__delete_from_swap_cache()/clear_shadow_from_swap_cache()
consume more time while workingset_update_node() be called much more times.

Since the patch result in consuming much more resource, and the problem this
patch try to solve is not apparent to user, we may abandon this patch.

By the way, as what this test result shows, mapping_set_update() should also
consume much time. Should we care about this?

Thanks.

Reproduce before this patch:
/vm-scalability-master # cat /sys/kernel/debug/tracing/trace_stat/function0
  Function                               Hit    Time            Avg             s^2
--------                               ---    ----            ---             ---
  add_to_swap_cache                    26108    476290.6 us     18.243 us       487.762 us
  __delete_from_swap_cache             26117    462492.6 us     17.708 us       77.801 us
  clear_shadow_from_swap_cache         27840    199925.1 us     7.181 us        313.126 us

Reproduce after this patch:
/vm-scalability-master # cat /sys/kernel/debug/tracing/trace_stat/function*
  Function                               Hit    Time            Avg             s^2
--------                               ---    ----            ---             ---
  add_to_swap_cache                    51268    1371819 us      26.757 us       676.311 us
  __delete_from_swap_cache             51260    1322712 us      25.803 us       123.010 us
  workingset_update_node              157455    770064.9 us     4.890 us        15.108 us
  clear_shadow_from_swap_cache         52928    563597.4 us     10.648 us       199.766 us