[PATCH] benchtests: Add pthread_once common-case test.
Adhemerval Zanella
azanella@linux.vnet.ibm.com
Thu Apr 10 13:44:00 GMT 2014
I know other already have reviewed it, but some comments:
On 08-10-2013 18:09, Torvald Riegel wrote:
> diff --git a/benchtests/Makefile b/benchtests/Makefile
> index aec395a..2eb1393 100644
> --- a/benchtests/Makefile
> +++ b/benchtests/Makefile
> @@ -20,8 +20,8 @@
> # Add benchmark functions in alphabetical order.
>
> subdir := benchtests
> -bench := acos acosh asin asinh atan atanh cos cosh exp log modf pow rint sin \
> - sincos sinh tan tanh
> +bench := acos acosh asin asinh atan atanh cos cosh exp log modf pow \
> + pthread_once rint sin sincos sinh tan tanh
I think it would be more logical to add it on NPTL tests rule, something like:
-benchset := $(string-bench-all) $(stdlib-bench)
+# Nptl function benchmarks.
+nptl-bench := pthread_once
+
+benchset := $(string-bench-all) $(stdlib-bench) $(nptl-bench)
> Yes, basically. More specifically, it's best-case latency, where we
> initialize once and then just read and read from it, even from the same
> thread.
> For #1, we could distinguish between:
> * Initialization by a single thread, no further use: Probably less
> likely to occur in practice, unless pthread_once is used conservatively
> and without real reason.
> * Concurrent init/use, no use afterwards: Multiple threads using
> pthread_once to agree on who does something.
>
> We could measure the latter, but this will be mostly an exercise in
> measuring consensus/CAS/lock performance on the particular machine --
> there's little we can do differently, except for everything we could
> also do to decrease memory contention in locks and the like.
I think current check (Latency of a call to pthread_once when initializing and thus
after initialization is done) is most likely the majority of pthread_once usage and
that what we need to aim for.
More information about the Libc-alpha
mailing list