On 6/27/24 15:46, Bruno Haible wrote:
The laptop uses an Intel Core i5-1335U.
So, 'cat /proc/cpuinfo' shows 12 CPUs, right?
Right.
The process had many threads active.
It should use 11 threads. You didn't see 100 threads, right?
Right.
gnulib-tool already has an option --with-longrunning-tests, for the same
purpose: Avoid exceedingly long test runs. Currently only a few tests modules
use it:
fts-tests
havelib-tests
system-quote-tests
vasnprintf-extra-tests
vasnwprintf-extra-tests
unistdio/u8-asnprintf-extra-tests
unistdio/ulc-asnprintf-extra-tests
obstack-zprintf-extra-tests
But let's investigate first...
Thanks for doing that investigating in your followup message. If glibc
won't fix this performance bug, perhaps we should mark this test as a
longrunning one? On my Pop_OS! laptop it's way slower than it was on any
of your measured VMs:
$ time ./test-pthread-rwlock
Starting test_rwlock ...Alarm clock
real 10m0.002s
user 90m18.341s
sys 9m38.634s
Alternatively we could work around the performance bug, though that may
be too much work to justify.
