[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAC2o3DJm0ugq60c8mBafjd81nPmhpBKBT5cCKWvc4rYT0dDgGg@mail.gmail.com>
Date: Wed, 12 May 2021 16:47:36 +0800
From: Fox Chen <foxhlchen@...il.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Ian Kent <raven@...maw.net>
Cc: Tejun Heo <tj@...nel.org>, Al Viro <viro@...iv.linux.org.uk>,
Eric Sandeen <sandeen@...deen.net>,
Brice Goglin <brice.goglin@...il.com>,
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: [PATCH v4 0/5] kernfs: proposed locking and concurrency improvement
Hi,
I ran it on my benchmark (https://github.com/foxhlchen/sysfs_benchmark).
machine: aws c5 (Intel Xeon with 96 logical cores)
kernel: v5.12
benchmark: create 96 threads and bind them to each core then run
open+read+close on a sysfs file simultaneously for 1000 times.
result:
Without the patchset, an open+read+close operation takes 550-570 us,
perf shows significant time(>40%) spending on mutex_lock.
After applying it, it takes 410-440 us for that operation and perf
shows only ~4% time on mutex_lock.
It's weird, I don't see a huge performance boost compared to v2, even
though there is no mutex problem from the perf report.
I've put console outputs and perf reports on the attachment for your reference.
thanks,
fox
Download attachment "result.after" of type "application/octet-stream" (5055 bytes)
Download attachment "result.before" of type "application/octet-stream" (5055 bytes)
Download attachment "report.before" of type "application/octet-stream" (325531 bytes)
Download attachment "report.after" of type "application/octet-stream" (396198 bytes)
Powered by blists - more mailing lists