From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8742 Path: news.gmane.org!not-for-mail From: Denys Vlasenko Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] configure: add gcc flags for better link-time optimization Date: Fri, 23 Oct 2015 16:41:17 +0200 Message-ID: References: <1445603426-4827-1-git-send-email-vda.linux@googlemail.com> <20151023131202.GI10551@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1445611334 26761 80.91.229.3 (23 Oct 2015 14:42:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 Oct 2015 14:42:14 +0000 (UTC) To: musl , Rich Felker , Denys Vlasenko Original-X-From: musl-return-8755-gllmg-musl=m.gmane.org@lists.openwall.com Fri Oct 23 16:42:01 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZpdXT-0000g8-Qu for gllmg-musl@m.gmane.org; Fri, 23 Oct 2015 16:41:51 +0200 Original-Received: (qmail 25953 invoked by uid 550); 23 Oct 2015 14:41:49 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 25932 invoked from network); 23 Oct 2015 14:41:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=SbLKlKEVJXITdi8JekTBJ76ywpJ+UXTOhYYo1lI3J+Y=; b=vyuEh+LIEHH494OYOAUh3C6nl992kvRxkmCqrV5cDG+l/PiZjR69a/IB9R9IoGanpx vWYtvI0cOJr6c+rsWn/rV0IfGHlQlg53vq/snFR9UgxtjbuYo+zE/HiuI2DMozxbKN96 JvKP0XVnXpOXe5xfEnShFx0BnllqltYGzHi5sMwAHpmveSdgBRqUkb/NT2X77/Cpm0KN 4c+nkM4zCsi9EHNg6UbzlrARad0yX1sHS94S6pju9VhsS09yrYGQA+5LJVEnHarV0ZrU ZAdNX3LuGlqB49wSca6G5BPT9YIAmdZU6Hzygt9AsA4npO0Gtw/6rom1rfo6iy4byRzj lOTQ== X-Received: by 10.55.221.22 with SMTP id n22mr26446034qki.60.1445611296949; Fri, 23 Oct 2015 07:41:36 -0700 (PDT) In-Reply-To: <20151023131202.GI10551@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:8742 Archived-At: On Fri, Oct 23, 2015 at 3:12 PM, Szabolcs Nagy wrote: >> +# When linker merges sections, a tiny section (such as one resulting >> +# from "static char flag_var") with no alignment restrictions >> +# can end up logded between two more strongly aligned ones (say, >> +# "static int global_cnt1/2", both of which want 32-bit alignment). >> +# Then this byte-sized "flag_var" gets 3 bytes of padding. >> +# >> +# With section sorting by alignment, one-byte flag variables have >> +# higher chance of being grouped together and not require padding. >> +# (It can be made even better. Linker is too dumb. >> +# ld needs to grow -Wl,--pack-sections-optimally) >> +# >> +# For us, this affects the size of only one file: libc.so >> +# >> +tryldflag LDFLAGS_AUTO -Wl,--sort-section=alignment >> +tryldflag LDFLAGS_AUTO -Wl,--sort-common > > i think this came up before > https://sourceware.org/bugzilla/show_bug.cgi?id=14156 > > it was also noted at some point that the optimal sorting > is 'sort by use' so all the unused legacy functions end > up on the same page so they never need to be loaded. Sure, but that would be quite hard to do. How would you reliably know who uses which part of libc code? OTOH, we don't _need_ to kill ourselves trying to optimize that. Optimizing code size is not the big thing here. Even though data and bss shrinkage is smaller, it is more important. Minimizing the number of data pages is more important than text pages. A text page is shared among all processes linked to this libc.so; data page is allocated in every process (as soon as even one byte in this page is written to. With only 4 pages in total like in this example, I'm pretty sure all of them get dirtied by libc init, use of stdio or malloc). Make libc (.data + .bss) fit into one page less and you get about as many pages saved as you have processes running.