From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30051 invoked by alias); 25 Nov 2014 13:37:09 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 30027 invoked by uid 48); 25 Nov 2014 13:37:05 -0000 From: "paulo.cesar.pereira.de.andrade at gmail dot com" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/17645] New: RFE: Improve performance of dynamic loader for deeply nested DSO dependencies. Date: Tue, 25 Nov 2014 13:37:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: paulo.cesar.pereira.de.andrade at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-11/txt/msg00193.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=17645 Bug ID: 17645 Summary: RFE: Improve performance of dynamic loader for deeply nested DSO dependencies. Product: glibc Version: unspecified Status: NEW Severity: normal Priority: P2 Component: dynamic-link Assignee: unassigned at sourceware dot org Reporter: paulo.cesar.pereira.de.andrade at gmail dot com Created attachment 7970 --> https://sourceware.org/bugzilla/attachment.cgi?id=7970&action=edit Sample "redistributable" test case provided by a customer After glibc-2.11, there are 3 slightly different instances of a very CPU intensive loop in elf/dl-deps.c, elf/dl-fini.c and elf/dl-open.c. The loop does not scale well when there are cyclic dependencies, and may take more than 8 seconds to sort less than 300 shared objects when there a some cycles. Most of the time is spent in memmove. Sample perf output of it taking 8+ secs on a core i5: 31,24% timedlopen ld-2.17.so [.] _dl_map_object_deps 18,36% timedlopen ld-2.17.so [.] _wordcopy_fwd_aligned 16,50% timedlopen ld-2.17.so [.] _dl_sort_fini 15,47% timedlopen ld-2.17.so [.] dl_open_worker 13,08% timedlopen ld-2.17.so [.] _wordcopy_fwd_dest_aligned 4,95% timedlopen ld-2.17.so [.] memmove 0,07% timedlopen ld-2.17.so [.] do_lookup_x I have been using a patch for some weeks in rhel-6.3 (for basic tests where the problem was detected/reported), and my day to day computers, running rhel-7 and fedora rawhide, and cannot see any problems running kde, gnome, libreoffice and several other large applications or environments that load/unload or have large dso dependency chains. The proposed patch runs the test case in 10 ms, and a sample perf output is: 17,45% timedlopen ld-2.17.so [.] do_lookup_x 9,54% timedlopen ld-2.17.so [.] strcmp 6,91% timedlopen ld-2.17.so [.] _dl_map_object_deps 6,12% timedlopen ld-2.17.so [.] _dl_name_match_p 4,35% timedlopen ld-2.17.so [.] _dl_sort_fini 4,33% timedlopen ld-2.17.so [.] dl_open_worker -- You are receiving this mail because: You are on the CC list for the bug.