This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: libc-alpha Digest 20 Sep 2018 12:41:32 -0000 Issue 6574
- From: Chris Aoki <christopher dot aoki at oracle dot com>
- To: libc-alpha at sourceware dot org
- Cc: Chris Aoki <christopher dot aoki at oracle dot com>
- Date: Thu, 20 Sep 2018 10:09:37 -0700
- Subject: Re: libc-alpha Digest 20 Sep 2018 12:41:32 -0000 Issue 6574
- References: <1537447292.42279.ezmlm@sourceware.org>
On Sep 20, 2018, at 5:41 AM, libc-alpha-digest-help@sourceware.org wrote:
>
> From: DJ Delorie <dj@redhat.com>
> Subject: when malloc runs out...
> Date: September 19, 2018 at 6:43:53 PM PDT
> To: libc-alpha@sourceware.org
> Cc: fweimer@redhat.com, Wilco Dijkstra <Wilco.Dijkstra@arm.com>
>
>
>
> I've recently been working on some problem cases wrt when malloc runs
> out of resources, and it's caused me to investigate all the failure
> modes therein.
> ...
> Long term, we might need some smarter way to scan through all the
> arenas, forcing a coalescing (i.e. purge the unsorted and fast bins)
> and checking to see if there's available chunks, when we know that the
> system is low on memory or mmaps. Or some way to periodically or
> deterministically re-assigning threads to arenas to balance them.
>
> Thoughts? Ideas?
If the system is fragmented at the mmap level, would it be possible
to find mmaps consisting entirely of free blocks (coalescing if necessary)
and unmap them? e.g. by equipping each mapping with a total-free-space
counter?
-chris