Messages in this thread | | | Date | Wed, 1 Oct 2014 07:28:32 +0200 | From | Ingo Molnar <> | Subject | Re: [RFC PATCH] Perf Bench: Locking Microbenchmark |
| |
* Tuan Bui <tuan.d.bui@hp.com> wrote:
> Subject: [RFC PATCH] Perf Bench: Locking Microbenchmark > > In response to this thread https://lkml.org/lkml/2014/2/11/93, > this is a micro benchmark that stresses locking contention in > the kernel with creat(2) system call by spawning multiple > processes to spam this system call. This workload generate > similar results and contentions in AIM7 fserver workload but > can generate outputs within seconds. > > With the creat(2) system call the contention vary on what locks > are used in the particular file system. I have ran this > benchmark only on ext4 and xfs file system. > > Running the creat workload on ext4 show contention in the mutex > lock that is used by ext4_orphan_add() and ext4_orphan_del() to > add or delete an inode from the list of inodes. At the same > time running the creat workload on xfs show contention in the > spinlock that is used by xsf_log_commit_cil() to commit a > transaction to the Committed Item List. > > Here is a comparison of this benchmark with AIM7 running > fserver workload at 500-1000 users along with a perf trace > running on ext4 file system. > > Test machine is a 8-sockets 80 cores Westmere system HT-off on > v3.17-rc6. > > AIM7 AIM7 perf-bench perf-bench > Users Jobs/min Jobs/min/child Ops/sec Ops/sec/child > 500 119668.25 239.34 104249 208 > 600 126074.90 210.12 106136 176 > 700 128662.42 183.80 106175 151 > 800 119822.05 149.78 106290 132 > 900 106150.25 117.94 105230 116 > 1000 104681.29 104.68 106489 106 > > Perf trace for AIM7 fserver: > 14.51% reaim [kernel.kallsyms] [k] osq_lock > 4.98% reaim reaim [.] add_long > 4.98% reaim reaim [.] add_int > 4.31% reaim [kernel.kallsyms] [k] mutex_spin_on_owner > ... > > Perf trace of perf bench creat > 22.37% locking-creat [kernel.kallsyms] [k] osq_lock > 5.77% locking-creat [kernel.kallsyms] [k] mutex_spin_on_owner > 5.31% locking-creat [kernel.kallsyms] [k] _raw_spin_lock > 5.15% locking-creat [jbd2] [k] jbd2_journal_put_journal_head > ...
Very nice!
If you compare an strace of AIM7 steady state and 'perf bench lock' steady state, is it comparable, i.e. do the syscalls and other behavioral patterns match up?
> +'locking':: > + Locking stressing benchmarks. > + > 'all':: > All benchmark subsystems. > > @@ -213,6 +216,11 @@ Suite for evaluating wake calls. > *requeue*:: > Suite for evaluating requeue calls. > > +SUITES FOR 'locking' > +~~~~~~~~~~~~~~~~~~ > +*creat*:: > +Suite for evaluating locking contention through creat(2).
So I'd display it in the help text prominently that it's a workload similar to the AIM7 workload.
> +static const struct option options[] = { > + OPT_UINTEGER('s', "start", &start_nr_threads, "Numbers of processes to start"), > + OPT_UINTEGER('e', "end", &end_nr_threads, "Numbers of process to end"), > + OPT_UINTEGER('i', "increment", &increment_threads_by, "Number of threads to increment)"), > + OPT_UINTEGER('r', "runtime", &bench_dur, "Specify benchmark runtime in seconds"), > + OPT_END() > +};
Is this the kind of parameters that AIM7 takes as well?
In any case, this is a very nice benchmarking utility.
Thanks,
Ingo
| |