unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
To: "Ondřej Bílka" <neleai@seznam.cz>, "Florian Weimer" <fweimer@redhat.com>
Cc: Carlos O'Donell <carlos@redhat.com>,
	Joseph Myers <joseph@codesourcery.com>,
	"libc-alpha@sourceware.org" <libc-alpha@sourceware.org>,
	nd <nd@arm.com>
Subject: Re: [PATCH v2] Add malloc micro benchmark
Date: Wed, 28 Feb 2018 17:01:57 +0000	[thread overview]
Message-ID: <DB6PR0801MB20537F726B53D8373CBD6BD083C70@DB6PR0801MB2053.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <20180228164621.GA10445@domone>

Ondřej Bílka wrote:
  
>> I think a heap-style allocator which does not segregate allocations
>> of different sizes still has its place, and why not provide one in
>> glibc?
>>
> That isn't case for any allocator and it is asking for trouble. You want
> to avoid sitation where two big chunks couldn't be merged because of
> tiny chunk between them.

Agreed, you always want to special case small blocks. I don't believe there is
any advantage in using a single big heap.

> For larger size this representation is still problematic and you could
> improve performance with another representation that also avoids
> alignment problem by placing metadata elsewhere(for mine only 4 bytes are needed).

Larger sizes would be helped a lot once small blocks are dealt with separately.
So I don't think we need complicated balanced binary trees when dealing with a
small number of large blocks. You won't need an unsorted list either, large blocks
can be merged in O(1) time.

There may be an advantage to place meta data elsewhere, for example it could make
adding/removing/walking free lists much faster (spatial locality) or to make heap
overflow attacks almost impossible,

Wilco


  reply	other threads:[~2018-02-28 17:00 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-01 13:51 [PATCH] Add malloc micro benchmark Wilco Dijkstra
2017-12-01 16:13 ` Carlos O'Donell
2017-12-18 15:18   ` Wilco Dijkstra
2017-12-18 16:32     ` Carlos O'Donell
2018-01-02 18:20       ` [PATCH v2] " Wilco Dijkstra
2018-01-02 18:45         ` DJ Delorie
2018-01-03 12:12           ` Wilco Dijkstra
2018-01-03 15:07             ` Carlos O'Donell
2018-01-04 13:48               ` Wilco Dijkstra
2018-01-04 16:37                 ` Adhemerval Zanella
2018-01-05 14:32                 ` Carlos O'Donell
2018-01-05 15:50                   ` Adhemerval Zanella
2018-01-05 16:17                     ` Carlos O'Donell
2018-01-05 16:46                       ` Adhemerval Zanella
2018-01-05 17:27                         ` Carlos O'Donell
2018-01-05 14:33         ` Carlos O'Donell
2018-01-05 16:28           ` Joseph Myers
2018-01-05 17:26             ` Carlos O'Donell
2018-02-28 12:40               ` Florian Weimer
2018-02-28 14:11                 ` Ondřej Bílka
2018-02-28 14:16                   ` Florian Weimer
2018-02-28 16:16                     ` Carlos O'Donell
2018-02-28 20:17                       ` Ondřej Bílka
2018-02-28 16:46                     ` Ondřej Bílka
2018-02-28 17:01                       ` Wilco Dijkstra [this message]
2018-02-28 18:21                         ` Carlos O'Donell
2018-02-28 19:56                         ` Ondřej Bílka
2018-02-28 21:56                           ` DJ Delorie
2018-03-01 11:24                             ` Ondřej Bílka
2017-12-18 23:02     ` [PATCH] " DJ Delorie
2017-12-28 14:09       ` Wilco Dijkstra
2017-12-28 19:01         ` DJ Delorie

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=DB6PR0801MB20537F726B53D8373CBD6BD083C70@DB6PR0801MB2053.eurprd08.prod.outlook.com \
    --to=wilco.dijkstra@arm.com \
    --cc=carlos@redhat.com \
    --cc=fweimer@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    --cc=nd@arm.com \
    --cc=neleai@seznam.cz \
    /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).