Re: [PATCH 3/7] benchtests: Add arc4random benchtest

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 14/04/2022 17:33, Noah Goldstein wrote:
> On Thu, Apr 14, 2022 at 2:48 PM Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>>
>>
>>
>> On 14/04/2022 16:17, Noah Goldstein wrote:
>>> On Wed, Apr 13, 2022 at 3:26 PM Adhemerval Zanella via Libc-alpha
>>> <libc-alpha@sourceware.org> wrote:
>>>>
>>>> It shows both throughput (total bytes obtained in the test duration)
>>>> and latecy for both arc4random and arc4random_buf with different
>>>> sizes.
>>>>
>>>> +
>>>> +static void *
>>>> +thr_arc4random_latency (void *closure)
>>>> +{
>>>> +  struct thr_arc4random_arg *arg = closure;
>>>> +  arg->ret = arg->val == 0 ? bench_arc4random_latency ()
>>>> +                          : bench_arc4random_buf_latency (arg->val);
>>>> +  return NULL;
>>>> +}
>>>
>>> I think the expectation is that the chacha calls will be cold,
>>> maybe it is worth adding a cache flush of sorts between
>>> calls. It may be some prefetching in the start will help the code in
>>> that case but would only be a regression with the hot in L1
>>> benchmarks.
>>>
>>> Can wait though this V1 looks fine.
>>
>> In fact I think just checking the call within a thread does not add
>> much, specially since we don't have any single-thread lock optimization
>> for internal locks.  I will remove it on v2 and maybe revise it in the
>> future.
> 
> What do you mean single-thread lock optimization?

Not take the lock if process is single-threaded, as we do on some fast-path
in malloc code.