This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/5] Add single-threaded path to malloc/realloc/calloc/memalloc
- From: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, nd <nd at arm dot com>
- Date: Thu, 12 Oct 2017 22:55:48 +0000
- Subject: Re: [PATCH 2/5] Add single-threaded path to malloc/realloc/calloc/memalloc
- 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: <DB6PR0801MB20538FF70A42648C916C69C0834B0@DB6PR0801MB2053.eurprd08.prod.outlook.com> (message from Wilco Dijkstra on Thu, 12 Oct 2017 09:35:26 +0000),<xnh8v46shj.fsf@greed.delorie.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
DJ Delorie wrote:
> Does SINGLE_THREAD_P return true if a multi-threaded app joins all its
> threads, so that there's only one thread remaining? If so, there will
> still be more arenas in play that might be usable, and the remaining
> thread might be better served by whatever arena it had been using, due
> to data locality on NUMA machines.
No that doesn't happen, so it's not a problem today.
> I also wonder if there's an upper limit to the main arena, where we'd
> have to use other arenas to fully use available VM.
Not as far as I can tell, there is the traditional stack and heap that grow
towards each other via sbrk. I don't believe you could reduce that since
mmaps in the middle would not be allowed.
> If either of these are issues, it might be better to conditionalize the
> lock calls than to duplicate the code, so we keep the alt-arena code in
> play.
That would mean sorting out all the locking in the arena code as well...
If we want to retry a different arena then the code that fails to allocate
more memory should do that (to avoid adding the retry in the fast path).
Wilco