linux-kernel - Re: [PATCH v4 0/8] make slab shrink lockless

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]

Date:   Wed, 8 Mar 2023 19:59:24 +0800
From:   Qi Zheng <zhengqi.arch@...edance.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     tkhai@...ru, hannes@...xchg.org, shakeelb@...gle.com,
        mhocko@...nel.org, roman.gushchin@...ux.dev, muchun.song@...ux.dev,
        david@...hat.com, shy828301@...il.com, rppt@...nel.org,
        sultan@...neltoast.com, dave@...olabs.net,
        penguin-kernel@...ove.SAKURA.ne.jp, paulmck@...nel.org,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 0/8] make slab shrink lockless


Hi Andrew,

On 2023/3/8 06:20, Andrew Morton wrote:
> On Tue,  7 Mar 2023 14:55:57 +0800 Qi Zheng <zhengqi.arch@...edance.com> wrote:
> 
>> Hi all,
>>
>> This patch series aims to make slab shrink lockless.
> 
> The v3 discussion did contain requests for some sort of measurements of
> real-world workloads.  And Kirill did suggest a workload which could be
> used for this measurement.
> 
> It's quite important that we have this info, please.  I mean, speeding
> up real-world workloads is the entire point of the patchset and without
> measurements, we don't know if the patchset achieves its primary
> objective!

I agree with this.

For the down_read_trylock() hotspot problem I encountered, I
posted a reproduction program in the cover letter, and measured the
change of IPC before and after applying the patchset.

For the case mentioned by Kirill, theoretically there is no competition
between slab shrink and register_shrinker() after applying this
patchset. But I haven't found a way to reproduce it yet, I will
continue to try to do it.

> 
> 
>> 3. Reproduction and testing
>> ===========================
>>
>> We can reproduce the down_read_trylock() hotspot through the following script:
>>
>> ```
>> #!/bin/bash
>>
>> DIR="/root/shrinker/memcg/mnt"
>>
>> do_create()
>> {
>>      mkdir -p /sys/fs/cgroup/memory/test
>>      mkdir -p /sys/fs/cgroup/perf_event/test
>>      echo 4G > /sys/fs/cgroup/memory/test/memory.limit_in_bytes
>>      for i in `seq 0 $1`;
>>      do
>>          mkdir -p /sys/fs/cgroup/memory/test/$i;
>>          echo $$ > /sys/fs/cgroup/memory/test/$i/cgroup.procs;
>>          echo $$ > /sys/fs/cgroup/perf_event/test/cgroup.procs;
>>          mkdir -p $DIR/$i;
>>      done
>> }
>>
>> do_mount()
>> {
>>      for i in `seq $1 $2`;
>>      do
>>          mount -t tmpfs $i $DIR/$i;
>>      done
>> }
>>
>> do_touch()
>> {
>>      for i in `seq $1 $2`;
>>      do
>>          echo $$ > /sys/fs/cgroup/memory/test/$i/cgroup.procs;
>>          echo $$ > /sys/fs/cgroup/perf_event/test/cgroup.procs;
>>              dd if=/dev/zero of=$DIR/$i/file$i bs=1M count=1 &
>>      done
>> }
>>
>> case "$1" in
>>    touch)
>>      do_touch $2 $3
>>      ;;
>>    test)
>>        do_create 4000
>>      do_mount 0 4000
>>      do_touch 0 3000
>>      ;;
>>    *)
>>      exit 1
>>      ;;
>> esac
>> ```
>>
>> Save the above script, then run test and touch commands. Then we can use the
>> following perf command to view hotspots:
> 
> Well.  Simply runnimg
> 
> 	time that-script

I tried this, but the script process will be killed because of OOM, so
the measured time is not accurate.

I will continue to try to measure more data besides IPC.

Thanks,
Qi

> 
> before and after and including the info in the changelog would be a start?