From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 63A713858D35 for ; Wed, 21 Jun 2023 19:39:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 63A713858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: by gnu.wildebeest.org (Postfix, from userid 1000) id 27F76313AC85; Wed, 21 Jun 2023 21:39:48 +0200 (CEST) Date: Wed, 21 Jun 2023 21:39:48 +0200 From: Mark Wielaard To: Romain GEISSLER Cc: "elfutils-devel@sourceware.org" , Francois RIGAULT Subject: Re: Performance issue with systemd-coredump and container process linking 2000 shared libraries. Message-ID: <20230621193948.GP24233@gnu.wildebeest.org> References: <20230614133920.10-1-romain.geissler@amadeus.com> <20230620213701.GN24233@gnu.wildebeest.org> <754003F4-3708-4C9C-AA30-EB76DAECF059@amadeus.com> <3465f95ee22b1ac433f1268f113e3813430be70a.camel@klomp.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-3029.7 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Romain, On Wed, Jun 21, 2023 at 06:14:27PM +0000, Romain GEISSLER wrote: > > Le 21 juin 2023 à 18:24, Mark Wielaard a écrit : > > > > Seeing those performance results I understand why you were suspecting > > the linked list data structure used in elf_getdata_rawchunk. > > > > Would you be able to test a rebuild libelf with the attached patch, > > which replaces that datastructure with a binary search tree? > > > > It didn't really show much speedup locally (in the noise, maybe 0.01 > > sec faster on ~0.25 sec run). But if there are more than 2000 calls to > > elf_getdata_rawchunk it should make things faster. > > Actually I have spent some time today to reproduce the issue for > real, using directly systemd. The details can be found in > https://github.com/systemd/systemd/pull/28093 which was just > merged. This change in systemd is enough to fix the biggest part of > the "slow" parsing of cores. Yet even with my systemd patch, we will > still call elf_getdata_rawchunk 2000 times if the crashing process > had 2000 shared libraries, so indeed your patch in elfutils might > still be welcome. I will test it later when I go home, or tomorrow. That patch looks good. It should reduce the number of calls to elf_getdata_rawchunk a lot. Making it less urgent that function is fast. But if you could test it that would be appreciated. I'll also test it a bit more and will probably merge it if no issues show up since it does seem better than keep using the linear list. Thanks, Mark