* Tuan Bui <tuan.d....@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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
