Matthew Dillon <[EMAIL PROTECTED]> writes:
> If you don't have the disk necessary for a standard overcommit model to
> work, you definitely do not have the disk necessary for a non-overcommit
> model to work.
I'd _really_ like to know how you figure this.
text data bss dec hex filename
45024 4096 392 49512 c168 /bin/cat
311264 12288 9900 333452 5168c /bin/sh
212960 4096 28492 245548 3bf2c inetd.static
458720 12288 73716 544724 84fd4 sendmail.static
None of these are particularly huge. Dynamically linked binaries
inflate things somewhat, of course, but even there:
442336 12288 35780 490404 77ba4 /usr/lib/libc.so.12.40
the data and bss per library just aren't that huge.
Of course, in addition to the sizes of the data and bss sections, you
need to make sure you've got enough extra for dynamically allocated
data, and for stack pages, and for a few other tidbits of dynamically
allocated storage, but the end result is a system which, even without
overcommit, can fit into a reasonable amount of backing store.
> Read the part again where I mentioned the swap requirements for a
> non-overcommit model to operate at the same level as the current model.
So, I just went back and looked at my mail folder for this NetBSD
mailing list (tech-userlevel), which has about a week and a half's
worth of messages.
Nowhere did I see what amounts to anything other than hand-waving
claims that you'll have to allocate much, much more backing store than
you currently need to, and claims that that's unacceptable for general
purpose computing environments. If you have a more specific analysis
that you'd like me/us to read, please point us at it more specifically.
Regarding those claims:
* not all the world's a general purpose computing environment,
* while you certainly need to allocate more backing store than you
would with overcommit, it's _not_ ridiculously more for most
applications(+), and, finally,
* even if you are not willing to pay that price, there _are_ people
who are quite willing to pay that price to get the benefits that they
see (whether it's a matter of perception or not, from their
perspective they may as well be real) of such a scheme.
(+): obviously, there are some applications for which no-overcommit is
just silly. However, 'normal' UNIX applications by and large allocate
memory (or map files writeable/private, or map anonymous memory) to
actually use it. I.e. if 'cat' or 'inetd' or 'sendmail' allocates a
page from the system, it's almost certainly going write something to
it, and, while there are undoubtedly a few pages that aren't written
to, they are by far the majority. And, of course, once the page has
been written, it's no longer reserved, it's committed. 8-)
I would honestly love to know: what do you see huge numbers of
reserved pages being reserved for, if they're not actually being
committed, by 'average' UNIX applications (for any definition of
average that excludes applications which do memory based computation
on sparse dasta).
cgd
--
Chris Demetriou - [EMAIL PROTECTED] - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message