From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id A2F3F1F732 for ; Sat, 10 Aug 2019 11:49:31 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:reply-to:subject:to:cc:references:from :message-id:date:mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=RYiSkxfr6wLlyoL8 ElcGV7ZgbKw5BX4R4kblnU71JkDuDiCkrP8OfdLN61FY4uNAOmsSLAKUz0n24PND zxlvQ0FyYhj/zpNryeVy2b1wXMncmdykONHvyHz4PeevrLRFXFdL1DPuWGc4/TTT BiSr+MMoDDMbrDJXqPokw3nEpPM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:reply-to:subject:to:cc:references:from :message-id:date:mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=L1Swe4dwLxLAoWnW9dCc7p zdorw=; b=uCeEgOokcp3d7+5PJ+poJ7nZTV3xqmwlCmvadaiex7riFV1EyPPQdT WhJj8rPFSvAO2aBUL/UK7iihoLsB5YPpLAkEcSMWEdSg+Xxnbwitdo5SkTx1fImK qJzQeIbxatI/b5rSgCFLUfPXt7wkFGsOBwB3xBOjcOeAVuC+tzc1c= Received: (qmail 80892 invoked by alias); 10 Aug 2019 11:49:28 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 80884 invoked by uid 89); 10 Aug 2019 11:49:28 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: esa4.mentor.iphmx.com IronPort-SDR: tdoHoByhSC7PBAZ7TtHEHaDVF7yg5o2CLqpjtbizCw2EpSIbHL8qOKItHbXsThnLTOzymbfCIf 7Q9vVimQ/wgAInUiScALGf6zjgKPzbqlA+Vg9LmQ03SuEeFC9Y5cwt5r+Bgy9C3nlfewnl0uti mUlGKUvQH5fghM7XowSgB8RZ6ASg5UgvaA8MByBLb+EL3N/ZOm8Nhz+6usyFElIY0IkPK2Dpot sRNU4tBDjYp/3fRFK6M0EHk74O7vzGxJwo2S9LY/x3XM/CDaGM7TBDlm71JrQapMUT+fY+6f9k 6Tw= IronPort-SDR: H9HG0V8kCDfeNBeP3n85MyMM3T52F7HWbWAFzKhXmtgBt1iSx2FdOwb7ZMK70PCGuSJ+JXQGNl an2VVC0Wlr0IFAwJq5ibxXP4l20FVakIhv7rKVnUhxNdvUfv3HDYEUQX2gjtZ34UhDaVHpLSv+ KA25UrpHGAoeur3vMuUYamOIaiNOcjT76WLnj6rp/pFeK2nG50hgZWa9B2QDG9YRkmV3EFftRr F+rTmTYzLDy9QdGc2O6WCTqO7LC1gXo7ZioimcBjBh/4z3oFdY79cNOk7KCzlIu0rweGcZ5s4i S68= Reply-To: Subject: Re: [PATCH 1/2][RFC] #17645, fix slow DSO sorting behavior in dynamic loader To: Florian Weimer CC: , GNU C Library References: <87h87crimv.fsf@oldenburg2.str.redhat.com> <87wog15fyy.fsf@oldenburg2.str.redhat.com> <87mugnao17.fsf@oldenburg2.str.redhat.com> From: Chung-Lin Tang Message-ID: Date: Sat, 10 Aug 2019 19:49:17 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <87mugnao17.fsf@oldenburg2.str.redhat.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit On 2019/8/5 6:45 PM, Florian Weimer wrote: >>>> What I did in the ld.so code patch was add a second pass of sorting >>>> that ignores runtime deps, prioritizing link dependencies; this >>>> appears to also be what prior discussion pointed towards, see more >>>> details in that 2nd email with the actual code patch. >>> I wonder if it makes sense to disentangle this (desirable) functional >>> change from the rest (which sould be purely an optimization). >> By "functional change" here, are you referring to the testing framework, >> or the described ld.so destructor behavior I described above? > The destructor behavior. Well, I'm definitely not suggesting adding the two-pass sorting described above with the current sorting algorithm (even if it should be relatively straightforward to do so) The entire #17645 issue is due to the current algorithm becoming prohibitively slow in certain pathological cases. Trying to fix the destructor behavior that way without replacing the current sorting algorithm will greatly exacerbate the performance problem. >>> Is it even necessary to re-sort on dlclose? Is the original dependency >>> order available somewhere? Then we could make it explicit that the >>> destructor order is the reverse of the constructor order (for the >>> objects unloaded). Or is there a corner case which causes an expected >>> divergence? >> Dynamic loaded objects could add more relocation dependencies, and >> thus augment the dependency relations (by adding more constraints), so >> a final sort should still be required. > Yes, these dynamically added relocation dependencies could mean that > fewer objects than had been loaded by the dlopen can be freed with > dlclose. But if we disregard those relocation dependencies for > destructor order sorting, wouldn't be the sorted result equivalent to > the constructor order? Relocation dependencies are not completely disregarded during destruction, just that they're prioritized lower than static link dependencies (when dependence cycles cause ambiguity in determining a single ordering), hence the two passes of sorting. Besides that, dlopen'ed but not dlclose'd objects also need to be processed along, so any existing already-computed ordering is probably not enough in the general case. Chung-Lin