bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: test-pthread-rwlock failure on Pop!_OS 22.04 LTS


From: Bruno Haible
Subject: Re: test-pthread-rwlock failure on Pop!_OS 22.04 LTS
Date: Fri, 28 Jun 2024 12:25:14 +0200

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 ./test-pthread-rwlock"

* in virtual machines with 8 CPUs:

  - Ubuntu 22.04                60 sec      (4 CPUs: 15 sec)
  - musl libc on Ubuntu 22.04    0.3 sec
  - Alpine Linux                 0.3 sec
  - FreeBSD 14                   1.4 sec
  - OpenBSD 7.5                  2.5 sec
  - Solaris 11.4                22 sec      (4 CPUs: 20 sec)
  - Cygwin                      33..35 sec  (4 CPUs: 25..27 sec)
  - mingw                       12 sec
  - MSVC                        16 sec

* outside VirtualBox:

  - Ubuntu 22.04 (12 CPUs)       6 sec
  - macOS 12                     3.6 sec
  - AIX 7.1                      4 sec

Intermediate results:

* While gl_cv_pthread_rwlock_rdlock_prefer_writer is
  - yes on macOS, FreeBSD, NetBSD, OpenBSD <= 6.0, Solaris, Cygwin,
  - no  on glibc, musl libc, OpenBSD >= 6.5, AIX, Android,
  only glibc has the problem; musl libc, OpenBSD 7.5, AIX don't.

* The first two measurements were done on the same Ubuntu 22.04 VM.
  This hints that kernel customization (scheduler, policies etc.)
  are not the cause — otherwise musl libc on Ubuntu 22.04 would have
  the same problem.

* I don't understand why the same Ubuntu 22.04 outside VirtualBox
  works fine (6 seconds), whereas inside VirtualBox it's 60 seconds.
  But it's not entirely a VirtualBox or virtualization problem,
  since in Paul's case the system is running on the naked harware
  (no virtualization).

So:
  - It seems to be a glibc problem.
  - But a large amount of CPU time is spent in the kernel.

Which performance tools exist that can help understand the situation
across the glibc / kernel boundary?

Bruno






reply via email to

[Prev in Thread] Current Thread [Next in Thread]