public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
From: Sivaprakasam Suresh <suresh420@yahoo.com>
To: libc-help@sourceware.org
Subject: pthread_rwlock_wrlock performance
Date: Tue, 23 Apr 2024 17:57:37 -0700	[thread overview]
Message-ID: <081D9537-0E1A-4447-AAEC-CCCFB2016C0E@yahoo.com> (raw)
In-Reply-To: <081D9537-0E1A-4447-AAEC-CCCFB2016C0E.ref@yahoo.com>

[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]

Hi,

We recently moved from el7 to el8, the glibc version changed from 2.17 to 2.28. We have a storage application which scales in pthreads, on 8cpu system it can scale dynamically from 8 to about 128 pthreads. We have noticed pthread_rwlock_wrlock performance is worse in 2.28 than from 2.17 as we goto higher thread counts. For lower thread counts 2.28 pthread_rwlock_wrlock performs better than 2.17 pthread_rwlock_wrlock when the ratio of vcpu to threads is lower but when its goes higher is when the performance is worse.

I investigated this further it appears around glibc 2.25 the implementation of pthread_rwlock_wrlock changed, we removed the internal locks and replaced with atomic increment, we spin more on cpu than we sleep. I think for higher thread counts we are likely seeing writer starvation because we are competing with spinning threads. We did bpftrace saw lock contention times increase with 2.28 compared to 2.17 all else remaining the same.

I have standalone test program where we have tried different thread counts, as we goto higher thread counts the performance worsens.

Has anyone encountered this problem ? Any suggestions what to do about this ? What is the next step ?

Regards,

-Suresh


           reply	other threads:[~2024-04-24  0:57 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <081D9537-0E1A-4447-AAEC-CCCFB2016C0E.ref@yahoo.com>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=081D9537-0E1A-4447-AAEC-CCCFB2016C0E@yahoo.com \
    --to=suresh420@yahoo.com \
    --cc=libc-help@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).