[PATCH] benchtests: Add libc locking benchmark
Carlos O'Donell
carlos@redhat.com
Fri Aug 19 01:38:34 GMT 2022
On 8/18/22 14:56, Wilco Dijkstra wrote:
> Hi Carlos,
>
>> You are using rand as a proxy for __libc_lock_lock() performance.
>>
>> Given that we build the benchtests/ within the same framework, can
>> we access glibc internals and try to benchmark the locks directly?
>>
>> Just like we have some tests using internals? If it doesn't work
>> out easily, then I think the current direction is fine.
>
> I don't believe there are tests for locking internals - the only tests that exist
> are the basic atomics and the pthread tests. Trying to include the locking
> headers resulted in lots of errors. The benchmarks are dynamically linked,
> so you can only test exported interfaces. I think we'd need to add extra
> exported (but not officially supported) functions if we want to benchmark
> internal locks directly.
Correct, there are no tests for locking internals, I just wondered if flipping the
module name and including the headers worked, but it sounds like it doesn't work out
of the box. Which is fine, I'm OK with benchmarking random() in a single-threaded and
multi-threaded scenario.
> Alternatively we could create a benchmark of standard lock implementations
> and run them in various scenarios. This could then be used to answer questions
> like whether we should prefer exchange or compare-exchange, whether locks
> should always spin for a short while (pthread locks do but internal locks don't)
> and further improve the internal locks.
Lets stick with benchmarking random() for now to move your other patch forward?
--
Cheers,
Carlos.
More information about the Libc-alpha
mailing list