public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: DJ Delorie <dj@redhat.com>,
	"libc-alpha@sourceware.org" <libc-alpha@sourceware.org>
Subject: Re: [PATCH] malloc: Use correct C11 atomics for fastbin
Date: Fri, 2 Dec 2022 12:02:21 +0000	[thread overview]
Message-ID: <PAWPR08MB898228A9045509C2E97AD33B83179@PAWPR08MB8982.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <87y1rqrqu9.fsf@oldenburg.str.redhat.com>

Hi Florian,

>> Yes, malloc is blocking but free isn't and accesses the freelist
>> concurrently.  It's a really weird design. Splitting the free list
>> into a local one and a shared one would be far better - no atomics
>> when you have the malloc lock, and if the local free list is empty it
>> takes one atomic to copy all shared entries.
>
> The local free list is in the tcache.  I think DJ said that removing the
> fastbins still resulted in a performance loss.
> 
> The tcache has also the benefit that the chain length is bounded.

That's because tcache has hardly any effect on programs with a high rate
of (de)allocations. It's so small that you usually end up using the fastbin
code anyway. All the singlethreaded optimizations in fastbins are absolutely
essential - that's the code that shows up in profiles.

If we want to make tcache actually work, it will have to support far more
allocations, particularly for smaller sizes.

Cheers,
Wilco

  reply	other threads:[~2022-12-02 12:02 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-21 16:09 Wilco Dijkstra
2022-11-21 16:18 ` Florian Weimer
2022-11-21 16:55   ` Wilco Dijkstra
2022-11-21 16:56     ` Wilco Dijkstra
2022-11-21 17:00     ` Florian Weimer
2022-12-02  5:11 ` DJ Delorie
2022-12-02  6:36   ` Florian Weimer
2022-12-02 10:56     ` Wilco Dijkstra
2022-12-02 11:24       ` Florian Weimer
2022-12-02 12:02         ` Wilco Dijkstra [this message]
2022-12-02 18:55           ` DJ Delorie
2022-12-05 18:39             ` Zack Weinberg
2022-12-06 16:19               ` DJ Delorie
2022-12-12  3:35                 ` Zack Weinberg
2022-12-12 11:57                   ` Florian Weimer
2022-12-12 11:56                 ` Florian Weimer
2022-12-06 13:29             ` Wilco Dijkstra
2022-12-06 13:37               ` Adhemerval Zanella Netto
2022-12-06 14:31                 ` Zack Weinberg
2022-12-06 16:23               ` DJ Delorie
2022-12-15 15:43                 ` Wilco Dijkstra
2022-12-02 18:55     ` DJ Delorie
2022-12-06 15:04 Wilco Dijkstra

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=PAWPR08MB898228A9045509C2E97AD33B83179@PAWPR08MB8982.eurprd08.prod.outlook.com \
    --to=wilco.dijkstra@arm.com \
    --cc=dj@redhat.com \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@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).