Subject: Re: Replacement for grep(1) (part 2)
To: Kevin Schoedel <firstname.lastname@example.org>
From: Daniel C. Sobral <email@example.com>
Date: 07/15/1999 23:33:37
Kevin Schoedel wrote:
> >Imagine a reasonably big
> >program, like Netscape or Emacs, of which you usually just use a
> >subset of features. There can easily be many megabytes of code and
> >data in them you never actually use, or you don't _usually_ use
> >(like the people who use emacs like it was vi :). Without
> >overcommit, you need to allocate all that memory for the code, no
> >matter whether you end up using it or not. With overcommit, there is
> >no such problem.
> Code, static data, and not-yet-written writable data should be backed by
> the executable file, not by swap space, so unused code and tables should
> not be a problem.
TEXT should be backed by the executable, as long a the program
doesn't change it to read/write. That's not the code I was refering
to. Not-yet-written blah-blah-blah should be backed by:
1) The executable file if you are overcommitting.
2) RAM/Swap if you are not. If you don't do this, you are
overcommitting. Proof: let the system exaust it's memory. Change a
single byte in the not-yet-written stuff. Now you need more memory
than you have to comply with a regular operation (like changing the
value of a global variable), which means you overcommitted.
Now comes the people saying "don't overcommit in *this* case, and
overcommit in *that* case". Irrelevant. Programs are still getting
killed because memory was overcommitted (with the added disadvantage
of you not having as much memory as in a full overcommit mode).
> Stack is more interesting. There might be a place for a global overcommit
> switch. I think I'd be happier with a scheme in which stack the first
> page or first few pages are committed (so that reasonable programs will
> never run into trouble) and remaining stack is over-/un-committed by
> default, along with means for unusual programs to commit (and/or test
> commitability of) subsequent pages.
Eh? Reasonable programs *never* run into trouble. Trouble only
happens when you have unreasonable programs around, or did not
configure the system correctly. And if you did not configure the
system correctly, why do you think you would be able to correctly
estimate the stack needed for the various programs?
Daniel C. Sobral (8-DCS)
"Would you like to go out with me?"
"I'd love to."
"Oh, well, n... err... would you?... ahh... huh... what do I do