Re: [PATCH] benchtests: Add pthread_once common-case test.

[Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>]

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.