This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [updated patch] malloc per-thread cache ready for review
- From: Florian Weimer <fweimer at redhat dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: libc-alpha at sourceware dot org, carlos at redhat dot com
- Date: Fri, 12 May 2017 08:41:05 +0200
- Subject: Re: [updated patch] malloc per-thread cache ready for review
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com A5DB830AF46
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A5DB830AF46
- References: <xn37camvvj.fsf@greed.delorie.com>
On 05/12/2017 08:28 AM, DJ Delorie wrote:
Florian Weimer <fweimer@redhat.com> writes:
Sorry, that's not what I meant. The thread cache adds some
workload-independent per-thread overhead to store the cache. We should
document how large that overhead is.
That's the math I put in the tunables docs.
Sorry, I missed that. It addresses my question.
Or did you mean the size of the table itself? Or the __thread data
size?
The additional __thread data is minuscule, right?
Thanks,
Florian