This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

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>, libc-alpha at sourceware dot org
Cc: Carlos O'Donell <carlos at redhat dot com>
Date: Fri, 12 May 2017 08:15:03 +0200
Subject: Re: [updated patch] malloc per-thread cache ready for review
Authentication-results: sourceware.org; auth=none
Authentication-results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-results: ext-mx08.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 63144C05973E
Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 63144C05973E
References: <xn60h7m66z.fsf@greed.delorie.com>

On 05/11/2017 11:31 PM, DJ Delorie wrote:

I would like to see some discussion of the per-thread overhead the
thread cache introduces, maybe along the documentation of the tunables,
both the static overhead (due to new per-thread state) and some bounds
on the additional per-thread allocation retention.

I put some math in the tunables docs, and also see
https://sourceware.org/ml/libc-alpha/2017-01/msg00452.html  where this
was discussed upstream.

Sorry, that's not what I meant. The thread cache adds someworkload-independent per-thread overhead to store the cache. We shoulddocument how large that overhead is.


Thanks,
Florian

Follow-Ups:
- Re: [updated patch] malloc per-thread cache ready for review
  - From: DJ Delorie

References:
- Re: [updated patch] malloc per-thread cache ready for review
  - From: DJ Delorie

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]