This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2] Add malloc micro benchmark
- From: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- To: Ondřej Bílka <neleai at seznam dot cz>, Florian Weimer <fweimer at redhat dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, nd <nd at arm dot com>
- Date: Wed, 28 Feb 2018 17:01:57 +0000
- Subject: Re: [PATCH v2] Add malloc micro benchmark
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Wilco dot Dijkstra at arm dot com;
- Nodisclaimer: True
- References: <bcc3af78-c1ac-2d24-6a6a-c14d6ca7dc96@redhat.com> <DB6PR0801MB20538A414F1659748E703918833C0@DB6PR0801MB2053.eurprd08.prod.outlook.com> <6ad98d83-d49b-25a3-ef01-e93e18f4740b@redhat.com> <DB6PR0801MB2053641333453CE91496266E83190@DB6PR0801MB2053.eurprd08.prod.outlook.com> <96b76d58-d2f0-2176-51e5-f6338ed079e1@redhat.com> <alpine.DEB.2.20.1801051621180.14880@digraph.polyomino.org.uk> <a55c0575-f89d-0a05-7269-e38653b2b16e@redhat.com> <165192eb-d815-867f-e1ba-0f9972eb19cd@redhat.com> <20180228141126.GA13073@domone> <808ed1e2-5945-0712-87a5-a0408de55fb0@redhat.com>,<20180228164621.GA10445@domone>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
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