Date: Thu, 15 Jul 1999 12:19:56 +0900 From: "Daniel C. Sobral" <dcs@newsguy.com> To: John Nemeth <jnemeth@victoria.tc.ca> Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) Message-ID: <378D535C.FD6D667C@newsguy.com> References: <199907141949.MAA11413@vtn1.victoria.tc.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
John Nemeth wrote: > > } > This is based upon your somewhat strange definition of "work". I assure > } > you that I have run many systems which don't use overcommit, and which I > } > quite frequently run into "out of VM" conditions, and which I can assure > } > you, work just fine. When they're getting to run out of VM, the system > } > is approaching paging death, which is as you'd expect (they're overloaded). > } > That is, adding more VM (more swap space) would be counterproductive. > } > } Would you care to name such systems? And, btw, a system consuming > } all memory is *not* necessarily approaching paging death. More > } likely, it is just storing a lot of data in the swap which will > } never be used (which is the whole point of overcommit in first > } place), and, thus, never paged in. > > If the data is stored in swap, then it is committed, whether the data > is used or not. Overcommitting only helps with memory that is allocated, > but not used. It's bad enough to have people in this debate that have > something of a clue, refusing to see the other side; we really don't need > people that have no clue at all. Or trollers. Letting it pass that you did not care to name such systems, let's try to make myself clear. You were talking about systems approaching "out of VM" condition, to use your words. This happens when almost all memory, RAM and swap, have been committed to programs, by definition. This can happen with things as simple as C++ objects being initialized, even if they then proceed to stay mainly inactive (C++ array initialization comes to mind). What I'm saying is that active usage of this committed memory is more unlikely than most of it being inactive, which still consumes swap but does not cause paging. > } Fine. Stay with the allocation of swap for DATA/BSS of each instance > } of the same program you are running. That alone is enough. > > Yes. In another post, you brought up the issue of TEXT. TEXT is > swapped in from the executable file and has been for a very long time. It > is simply not an issue. I never said TEXT. I said *CODE*. Like in Megabytes of modifiable Lisp code used by Emacs, the program I mentioned. Some of us have enough experience not to automatically equate code with TEXT, which is a C-ish thingy. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?378D535C.FD6D667C>