Date: Mon, 10 Sep 2007 12:38:32 +0100 From: Thomas Sparrevohn <Thomas.Sparrevohn@btinternet.com> To: freebsd-amd64@freebsd.org Subject: Re: amd64 process sizes Message-ID: <200709101238.32403.Thomas.Sparrevohn@btinternet.com> In-Reply-To: <20070910104305.GA53667@deviant.kiev.zoral.com.ua> References: <20070905095049.GH1167@turion.vk2pj.dyndns.org> <20070910101850.GA1146@turion.vk2pj.dyndns.org> <20070910104305.GA53667@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 10 September 2007 11:43:05 Kostik Belousov wrote: > > > > I can see the usefulness of superpages for large objects (like the > > kernel and database buffer caches) but do they actually have much > > benefit for normal executables and shared libraries? Looking through > > my set of .so's, I only have 6 that have text segments larger than > > 2MiB (though a 7th is close to 2MiB), the largest (libwx_gtk2) is only > > 5MiB. None of the data or bss segments are larger than 2MiB and (the > > largest is 1.8MiB). > > Well - one idea could be to create combined library maps e.g. Tag multiple libraries against a static location map - One could tag the executeable with a unique identifier in order to overcome update issues - However I am not sure that it would give benefits as I believe that there are a limited number of superpage PTE's (I believe, not sure however) Ideally all - or maybe not all - libraries text part could be mapped into a fixed region that could be shared using superpages and global pages
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200709101238.32403.Thomas.Sparrevohn>