Pádraig Brady wrote:
> It failed again the same way with the latest gnulib.
> Note the test is run with `make -j24 check` from crontab.
Yeah, this test is known to fail under load. There is no way to make it
100% reliable under high load. Even if I was to choose a STEP_INTERVAL of
1 second, it wou
On 09/08/2024 11:03, Bruno Haible wrote:
Pádraig Brady wrote:
FYI coreutils CI started failing with this on cfarm13.cfarm.net (debian 11.9)
with:
FAIL: test-pthread-rwlock-waitqueue
===
test-pthread-rwlock-waitqueue.c:234: assertion 'startswith (do_test ("R"
Pádraig Brady wrote:
> FYI coreutils CI started failing with this on cfarm13.cfarm.net (debian 11.9)
> with:
>
> FAIL: test-pthread-rwlock-waitqueue
> ===
> test-pthread-rwlock-waitqueue.c:234: assertion 'startswith (do_test
> ("R"), " R1 R2 R3 R4 R5")' failed
On 07/08/2024 18:56, Bruno Haible wrote:
On 2024-07-07, I stated:
This provides enough justification for gnulib to override the glibc behaviour
here. I will therefore go ahead and override
PTHREAD_RWLOCK_INITIALIZER
pthread_rwlock_init
pthread_rwlock_attr_init
to use PREFER_WRITER or PR
On 2024-07-07, I stated:
> This provides enough justification for gnulib to override the glibc behaviour
> here. I will therefore go ahead and override
> PTHREAD_RWLOCK_INITIALIZER
> pthread_rwlock_init
> pthread_rwlock_attr_init
> to use PREFER_WRITER or PREFER_WRITER_NONRECURSIVE, which bot
Paul Eggert wrote:
> >1. Install a toolchain for creating binaries linked against musl-libc:
> > $ sudo apt install musl-gcc
> >2. Create a testdir for the module 'pthread-rwlock'.
> >3. Build it with CC="gcc". You should still see the test failure after
> > 10 minutes.
> >
On 6/29/24 02:48, Bruno Haible wrote:
1. Install a toolchain for creating binaries linked against musl-libc:
$ sudo apt install musl-gcc
2. Create a testdir for the module 'pthread-rwlock'.
3. Build it with CC="gcc". You should still see the test failure after
10 minutes.
Hi Paul,
These measurements:
> * in virtual machines with 8 CPUs:
>
> - Ubuntu 22.0460 sec (4 CPUs: 15 sec)
>
> * outside VirtualBox:
>
> - Ubuntu 22.04 (12 CPUs) 6 sec
together with the investigation of the pthread_cond_timedwait "bug",
makes it sound possible
Some more measurements in virtual machines with 8 CPUs:
Debian 9 (glibc 2.24) 4 CPUs: 0.33 sec 8 CPUs: 0.34 sec
Debian 10 (glibc 2.28) 4 CPUs: 23 sec8 CPUs: 29 sec
So, while glibc < 2.25 did not prefer writers (like musl libc, OpenBSD 7.5,
AIX), it's only starting with
I wrote:
> 3) This topic has been discussed in the glibc bug
> https://sourceware.org/bugzilla/show_bug.cgi?id=13701
> where I have raised my voice for a writer-preferring implementation.
The rwlock implementation being not writer-preferring appears to be
only one contributing factor.
I did "time
On 6/28/24 01:44, Bruno Haible wrote:
Paul Eggert wrote:
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
real10m0.002s
user90m18.341s
sys 9m38.634s
Indeed, that's 5 times slower...
It
Paul Eggert wrote:
> 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
Indeed, that's 5 times slower...
> Alternatively we could work ar
> So, in summary, it's a glibc bug that has been closed as "WORKSFORME" and
> will never be fixed [3].
>
> In the test-pthread-rwlock test, we cannot just use
> PTHREAD_RWLOCK_WRITER_NONRECURSIVE_INITIALIZER_NP, because the *purpose* of
> the test is to check the behaviour of the rwlocks with the
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-longru
Bruno Haible writes:
> Can you please
> * measure the execution time of each of the locking tests?
Sure. Let me know if there is any other tests you need run.
> test-pthread-mutex
$ time ./gltests/test-pthread-mutex
Starting test_pthread_mutex_normal ... OK
Starting test_pthread_mutex_recurs
Collin Funk wrote:
> It was one of the locking tests but I forget if it was test-pthread-rwlock.
Can you please
* measure the execution time of each of the locking tests?
test-pthread-mutex
test-pthread-rwlock
test-lock
test-rwlock1
test-mtx
* tell how many threads your machine supports?
Hi Paul,
I wrote:
> > The process had many threads active.
>
> It should use 11 threads. You didn't see 100 threads, right?
Looking at the test's code, it should use 21 threads.
1) I measured the execution time of this test, on various distributions,
with various kernels, and various numbers o
Hi Bruno,
Bruno Haible writes:
> 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.
If it helps you investigate I think I ran into a similar issue when
building findutils on a NetBSD 10.0 virtual machine
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 eventual
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 ki
20 matches
Mail list logo
