From: Carlos O'Donell <email@example.com> To: "Wilco Dijkstra" <Wilco.Dijkstra@arm.com>, "Ondřej Bílka" <firstname.lastname@example.org>, "Florian Weimer" <email@example.com> Cc: Joseph Myers <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, nd <email@example.com> Subject: Re: [PATCH v2] Add malloc micro benchmark Date: Wed, 28 Feb 2018 10:21:20 -0800 Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <DB6PR0801MB20537F726B53D8373CBD6BD083C70@DB6PR0801MB2053.eurprd08.prod.outlook.com> On 02/28/2018 09:01 AM, Wilco Dijkstra wrote: > 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, I agree with many of the things you and Ondrej are proposing. The outcome of our current discussions should be an incremental plan to go from where we are today, to where we want to be tomorrow. However, I do *not* believe it is a good plan to simply throw away the present allocator and claim it should be replaced from scratch. We do not have that luxury as a core project, we must remain answerable to our users. A high-level concrete problem today with glibc's malloc, and the only problem being reported by our users is that it consumes too much RSS. Solving that problem in the abstract is what we should be looking at. If we think that having multiple heaps for different sized objects is the way to do this, then we should think about how to go down that path with an experiment. Any cleanup we do before that is a win. -- Cheers, Carlos.
next prev parent reply index Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-12-01 13:51 [PATCH] " 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 2018-02-28 18:21 ` Carlos O'Donell [this message] 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 \ --email@example.com \ --firstname.lastname@example.org \ --cc=Wilco.Dijkstra@arm.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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
unofficial mirror of firstname.lastname@example.org Archives are clonable: git clone --mirror https://public-inbox.org/libc-alpha/0 libc-alpha/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 libc-alpha libc-alpha/ https://public-inbox.org/libc-alpha \ email@example.com public-inbox-index libc-alpha Example config snippet for mirrors Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.lib.glibc.alpha nntp://ou63pmih66umazou.onion/inbox.comp.lib.glibc.alpha nntp://news.gmane.io/gmane.comp.lib.glibc.alpha note: .onion URLs require Tor: https://www.torproject.org/ AGPL code for this site: git clone https://public-inbox.org/public-inbox.git