unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Carlos O'Donell <carlos@redhat.com>
To: Eric Wong <normalperson@yhbt.net>, libc-alpha@sourceware.org
Subject: Re: [RFC/PoC] malloc: use wfcqueue to speed up remote frees
Date: Tue, 31 Jul 2018 08:16:08 -0400	[thread overview]
Message-ID: <0cfdccea-d173-486c-85f4-27e285a30a1a@redhat.com> (raw)
In-Reply-To: <20180731084936.g4yw6wnvt677miti@dcvr>

On 07/31/2018 04:49 AM, Eric Wong wrote:
> The goal is to reduce contention and improve locality of cross-thread
> malloc/free traffic common to IPC systems (including Userspace-RCU) and
> some garbage-collected runtimes.
Eric,

This looks like a really interesting contribution!

For anyone reviewing this patch I just want to point out that Eric *does*
have FSF copyright assignment for glibc, so review can proceed normally
for this patch. Thank you!

I would like to see urcu used within glibc to provide better data structures
for key thread, dynamic loader, and malloc algorithms. So if anything I think
this is a move in the right direction.

It would be interesting to roll your RFC into Fedora Rawhide for 6 months and
see if we hit any problems.

I have a few high-level questions:

- Can you explain the RSS reduction given this patch? You might think that just
  adding the frees to a queue wouldn't result in any RSS gains. However, you
  are calling _int_free a lot in row and that deinterleaving may help (you really
  want vector free API here so you don't walk all the lists so many times, tcache
  had the same problem but in reverse for finding chunks). 

- Adding urcu as a build-time dependency is not acceptable for bootstrap, instead
  we would bundle a copy of urcu and keep it in sync with upstream. Would that
  make your work easier?

- What problems are you having with `make -j4 check?' Try master and report back.
  We are about to release 2.28 so it should build and pass.

Thank you again for testing this out.

-- 
Cheers,
Carlos.

  reply	other threads:[~2018-07-31 12:16 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-31  8:49 [RFC/PoC] malloc: use wfcqueue to speed up remote frees Eric Wong
2018-07-31 12:16 ` Carlos O'Donell [this message]
2018-07-31 23:18   ` Eric Wong
2018-08-01  4:41     ` Carlos O'Donell
2018-08-01  6:23       ` Eric Wong
2018-08-01  7:01         ` Carlos O'Donell
2018-08-01  9:26           ` Eric Wong
2018-08-02 21:38             ` Carlos O'Donell
2023-01-17  6:42       ` Eric Wong via Libc-alpha
2023-01-17 19:05         ` Mathieu Desnoyers via Libc-alpha
2023-01-18 15:48           ` Mathieu Desnoyers via Libc-alpha
2023-01-18 19:12             ` Eric Wong via Libc-alpha
2023-01-18 19:17               ` Mathieu Desnoyers via Libc-alpha
2023-01-18 20:05                 ` Eric Wong via Libc-alpha
2023-01-18 14:53         ` Mathieu Desnoyers via Libc-alpha
2023-01-18 14:58           ` Mathieu Desnoyers via Libc-alpha
2018-08-08 10:40   ` Eric Wong

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

  List information: https://www.gnu.org/software/libc/involved.html

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

  git send-email \
    --in-reply-to=0cfdccea-d173-486c-85f4-27e285a30a1a@redhat.com \
    --to=carlos@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=normalperson@yhbt.net \
    /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).