From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47423 invoked by alias); 29 Oct 2019 20:17:52 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 47409 invoked by uid 89); 29 Oct 2019 20:17:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy= X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 29 Oct 2019 20:17:50 +0000 Received: from librem (deer0x15.wildebeest.org [172.31.17.151]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id BB970302BB3C; Tue, 29 Oct 2019 21:17:45 +0100 (CET) Received: by librem (Postfix, from userid 1000) id 037B7C029A; Tue, 29 Oct 2019 21:17:42 +0100 (CET) Date: Tue, 29 Oct 2019 20:17:00 -0000 From: Mark Wielaard To: Jonathon Anderson Cc: elfutils-devel@sourceware.org Subject: Re: [PATCH 0/2] libdw: Rewrite the memory handler to be more robust Message-ID: <20191029201742.GG2775@wildebeest.org> References: <1572375325.2128.1@rice.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1572375325.2128.1@rice.edu> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Flag: NO X-IsSubscribed: yes X-SW-Source: 2019-q4/txt/msg00075.txt.bz2 Hi Jonathon, On Tue, Oct 29, 2019 at 01:55:25PM -0500, Jonathon Anderson wrote: > This is (revived and rebased) version of the libdw memory manager that isn't > affected by the PTHREAD_KEYS_MAX limit. There are some downsides, in > particular if an application spawns many short-lived threads that all touch > a Dwarf (enough to cause an allocation), there's about ~8N bytes of memory > overhead. Thanks. But it looks like your mail client munged the patches a bit making it a bit tricky to apply. Could you resent them using git send-email or do you have some public repo I could get them from? Thanks, Mark