Hi Paul,
> When running './gnulib-tool --test nstrftime" on my laptop's Pop!_OS
> 22.04 LTS, test-pthread-rwlock went into what appeared to be a CPU bound
> infinite loop. It would have drained the battery if I hadn't been
> plugged into the wall. The process had many threads active. I eventually
> gave up and killed the test.
>
> Pop!_OS is downstream of Ubuntu, and this version is using glibc
> 2.35-0ubuntu3.8. uname -srvmpi reports "Linux 6.9.3-76060903-generic
> #202405300957~1718348209~22.04~7817b67 SMP PREEMPT_DYNAMIC Mon J x86_64
> x86_64 x86_64".
Interesting. On my system — also 2.35-0ubuntu3.8 — the test completes
in ca. 7 seconds each time.
I'll try to reproduce and investigate.
From the details that you gave, the culprit could well be with the
kernel: Linux 6.9.3 ... PREEMPT_DYNAMIC.
> The laptop uses an Intel Core i5-1335U.
So, 'cat /proc/cpuinfo' shows 12 CPUs, right?
> The process had many threads active.
It should use 11 threads. You didn't see 100 threads, right?
> I suggest redoing the pthread tests so that they run in far less than
> the current 10 minutes of real time before abandoning the test.
The test needs a certain number of rounds, in order to distinguish good
from bad implementations, as the comment says:
/* Number of operations performed in each thread.
This is quite high, because with a smaller count, say 5000, we often get
an "OK" result even without ENABLE_LOCKING (on Linux/x86). */
#define REPEAT_COUNT 50000
The 10 minutes of timeout could certainly be reduced, at least when not
running in a QEMU-based VM.
> perhaps we should add a
> new option --expensive to ./gnulib-tool, to cause it to also run
> expensive tests, and mark the pthread tests as expensive.
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...
Bruno
