From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2974 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Difficulty emulating F_DUPFD_CLOEXEC Date: Sat, 23 Mar 2013 23:08:00 -0400 Message-ID: <20130324030800.GE20323@brightrain.aerifal.cx> References: <20130324015923.GA5905@brightrain.aerifal.cx> <514E6082.4070104@eservices.virginia.edu> <20130324021707.GB20323@brightrain.aerifal.cx> <514E6482.1050708@eservices.virginia.edu> <20130324023338.GC20323@brightrain.aerifal.cx> <514E6BAF.2000604@eservices.virginia.edu> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1364094490 31465 80.91.229.3 (24 Mar 2013 03:08:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Mar 2013 03:08:10 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2975-gllmg-musl=m.gmane.org@lists.openwall.com Sun Mar 24 04:08:37 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UJbIS-000732-TV for gllmg-musl@plane.gmane.org; Sun, 24 Mar 2013 04:08:37 +0100 Original-Received: (qmail 20333 invoked by uid 550); 24 Mar 2013 03:08:12 -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 20324 invoked from network); 24 Mar 2013 03:08:12 -0000 Content-Disposition: inline In-Reply-To: <514E6BAF.2000604@eservices.virginia.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2974 Archived-At: On Sat, Mar 23, 2013 at 10:57:51PM -0400, Zvi Gilboa wrote: > >One byte of data should not really matter, but in a sense it does > >because you have to worry that the linking order might put it in the > >middle of an otherwise-unused page and thus increase the memory usage > >of the whole process by a page. This is actually an issue we need to > >address -- libc.so's memory usage is a lot higher than it should be > >right now, because the global vars that get touched by EVERY process > >at startup time are spread out across several pages. Ordering things > >so that they all end up in the same page would fix it, but I'm still > >looking for the cleanest way to do that.. > > .... could a structure holding all global variables be considered a > clean way to achieve this? That would obviously mandate some code > changes (adding the extern declaration to the relevant modules, and > accordingly referring to global_vars.var_one instead of just to > var_one), but at least "guarantee" that they are all kept together > on the same page (or two or three)... That's what we do for some data that's known to be needed in _all_ programs (see the "libc" structure in internal/libc.[ch]), but it's problematic for static linking if the data might or might not be needed, and you want to let the linker omit it when it's not needed. So far I've seen two half-decent approaches: 1. Put all the almost-surely-touched data in .data rather than .bss. The amount of .data is small enough that it all fits in one page anyway. The trade-off here is that .data takes space on disk (even if it's zero-filled), so you increase the size of libc.so and static-linked binaries slightly on disk. 2. Reorder the linking/archiving of .o files so that the ones with almost-surely-touched data appear first in the link order. The trade-off here is that the source tree and/or Makefile becomes a bit uglier. Of these, I tend to prefer the first. However, it still might not be enough for fully optimal layout. For example, we'd like the likely-to-be-used parts of .bss to immediately follow .data (in the same page): things like the buffers for stdin and stdout, which are not _necessarily_ used, but fairly likely to be used. Other big .bss buffers like pthread_key_create tables, which are unlikely to be used, should be at the end in hopes that the last few pages of .bss won't be dirtied at all. Rich