Date: Thu, 03 Aug 1995 21:31:54 -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: <199508040431.VAA13459@corbin.Root.COM> In-Reply-To: Your message of "Thu, 03 Aug 95 19:12:39 -0800." <199508040309.AA11016@diamond.sierra.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>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. Because mapped files aren't included at all in the VSZ reported by 'ps'. This is a bug and needs to be fixed. Someday. >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". Because FreeBSD maps all resident pages into the process at map time to drastically reduce soft page faults (and thus measurably improve performance). -DG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508040431.VAA13459>