linux-kernel - Re: [REPOST PATCH v4 0/5] kernfs: proposed locking and concurrency improvement

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: <CAC2o3DJZvVC1q+92DeUQ2yLHWAej2YkRuTKPdus50PxF+z94Hw@mail.gmail.com>
Date:   Sun, 30 May 2021 12:44:09 +0800
From:   Fox Chen <foxhlchen@...il.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Ian Kent <raven@...maw.net>, Tejun Heo <tj@...nel.org>,
        Eric Sandeen <sandeen@...deen.net>,
        Brice Goglin <brice.goglin@...il.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Rick Lindsley <ricklind@...ux.vnet.ibm.com>,
        David Howells <dhowells@...hat.com>,
        Miklos Szeredi <miklos@...redi.hu>,
        Marcelo Tosatti <mtosatti@...hat.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [REPOST PATCH v4 0/5] kernfs: proposed locking and concurrency improvement

On Fri, May 28, 2021 at 4:56 PM Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
>
> Fox, can you take some time and test these to verify it all still works
> properly with your benchmarks?
>

I've tested it on an AWS C5a (amd, 96 logical cores):
Before, mutex_locks in kernfs_iop_permission(), kernfs_dop_revalidate
take significant time.
With the patchset, there is no mutex_lock issue. (see flamegraph
before.png/after.png)

On AWS C5 (intel, also 96 logical cores), the benchmark runs slower
than on c5a. But I don't think it's related, because
running the benchmark on ext4 is slower too, and the perf report,
which is no different from running on kernfs with this patchset,
shows the pressure is on the VFS side.

My conclusion: It works well with my benchmark.

I've attached:
flame graphs -- before.png/after.png
benchmark outputs -- result.before/result.after
perf reports -- report.before/report.after
perf report on ext4 -- report.baremetal.ext4
for you reference.

thanks,
fox

Download attachment "after.png" of type "image/png" (92577 bytes)

Download attachment "before.png" of type "image/png" (86972 bytes)

Download attachment "result.before" of type "application/octet-stream" (5055 bytes)

Download attachment "result.after" of type "application/octet-stream" (4927 bytes)

Download attachment "report.after" of type "application/octet-stream" (212796 bytes)

Download attachment "report.before" of type "application/octet-stream" (166611 bytes)

Download attachment "report.baremetal.ext4" of type "application/octet-stream" (158847 bytes)