Date: Thu, 03 Aug 1995 14:10:16 -0700 From: David Greenman <davidg@Root.COM> To: jiho@sierra.net Cc: freebsd-questions@freefall.cdrom.com Subject: Re: 2.0.5 Eager to go into swap Message-ID: <199508032110.OAA04549@corbin.Root.COM> In-Reply-To: Your message of "Thu, 03 Aug 95 10:59:12 -0800." <199508031855.AA08146@diamond.sierra.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>> to do about it. Ironically, shared libraries are supposed to help this >> situation, but in FreeBSD they are so un-optimally ordered that applications >> wind up consuming as much memory as they would if built non-shared (static). >> The solution to this problem is to order the routines so that commonly used >> ones are all grouped together, and further group together related routines. >> This is difficult for two reasons: first, we don't have the statistics to know >> how to order the routines properly, and second, our library build procedure >> really doesn't allow for this. >> >> -DG >> > >Wait a minute, in FreeBSD shared libraries are MAPPED in by >ld.so using the mmap() function, using copy-on-write with text >(code) pages marked read-only. That means shared libraries >are used in as page-efficient a manner as is humanly possible, >with virtually no human intervention. Physical RAM pages >(4 KB chunks) are occupied as they are accessed, on the fly.... >or at least, that's how it's supposed to work. Since mmap() >syncs properly with files on disk, I have no reason to doubt it >on this point. ... >Right? Am I missing something here? Yes, you completely missed the point I was making above. Shared libraries are large and contain mostly things that your program doesn't use. Since the routines that it does use are spread out over the entire library, applications tend to fault in a whole page of stuff when only a handful of bytes is actually needed. This has two affects: first, in a short time, the entire shared portion of the library is faulted in (and when considering all of the libraries, including X, might be megabytes more stuff than is actually needed), and second, applications end up consuming a lot more private memory because of the copy-on-write that occurs on the data pages and the sparse references to the .bss pages. All of this together results in little, none, or negative memory savings over simply having everything built non-shared (which implies that only those functions actually used by the problem will be compiled in). The only solution to this problem is to order the shared libraries in such a way that things are grouped to make accesses as concentrated as possible. That is what Linux does, and that is one reason why it generally uses less memory than FreeBSD. Another reason is that it's malloc actually works right (unlike ours which often uses twice as much memory as is needed). -DG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508032110.OAA04549>