Date: Thu, 3 Aug 1995 19:12:39 -0800 From: "Jim Howard" <jiho@sierra.net> To: davidg@root.com, freebsd-questions@freefall.cdrom.com Subject: Re: 2.0.5 Eager to go into swap Message-ID: <199508040309.AA11016@diamond.sierra.net>
next in thread | raw e-mail | index | archive | help
> 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 You know, I just double checked my ps readouts, and you've certainly got a much better point than my recollection suggested when I read your message. The "run time set size" values tend to be a LOT larger than the "virtual memory size" values, especially for the X programs (though not for the server itself). But doesn't each library file from which resources are linked get mapped in its entirety (all text, data and bss) into each linking process's virtual memory space? In that case, how could the "run time set size" be much larger than the "virtual memory size"? It simply represents how many pages of the virtual memory space are actually in core at the moment. And even though ps reports a "run time set size" that doesn't distinguish shared from private pages (so one would expect overlap between processes), why would it report pages a process hasn't accessed? In other words, if a process doesn't access an entire library, something less than all of that library's pages should be reflected in that process's "run time set size", even though the size of the entire library is reflected in the process's "virtual memory size". It makes even less sense than ever to me now! But even if you can explain that to me, I still don't see what it has to do with swapping.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508040309.AA11016>