Robert Elz wrote:
>
> Note that all this (large) VM I have described was filled with real data
> (except for the odd times hen innd or named had just forked), none of it
> could be overcommitted and just ignored. Whatever policy was in place,
> the physical VM resources would have run out.
In a standard Unix system, with standard Unix programs, it is very
unlikely that "all this VM" was filled with real data. Take, for
instance, the stacks.
> Now, with overcommit mode, we get an extra 30 seconds of life, because
> no doubt there are a few pages floating around that have been allocated
> to some process, but nothing has bothered to write into yet. An extra 30
> seconds if we're lucky (except if we followed the advice given here
> earlier which would indicate that only 1/8 the amount of swap space would
> be needed, in which case these processes would never have gotten started
> in the first place). After that short grace period, during which the
Which is what I claim. Have you run it in overcommit mode? Did you
actually get just 30 extra seconds? Sure as hell, the AIX systems I
ran would have gotten a LOT more than 30 extra seconds going from
non-overcommit to overcommit.
--
Daniel C. Sobral (8-DCS)
d...@newsguy.com
d...@freebsd.org
"Would you like to go out with me?"
"I'd love to."
"Oh, well, n... err... would you?... ahh... huh... what do I do
next?"
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
