Date: Thu, 15 Jul 1999 00:53:17 +0900 From: "Daniel C. Sobral" <dcs@newsguy.com> To: Robert Elz <kre@munnari.OZ.AU> Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) Message-ID: <378CB26D.C0BC0DBE@newsguy.com> References: <8132.931941329@cs.mu.OZ.AU>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Elz wrote: > > Date: Tue, 13 Jul 1999 14:14:52 -0700 (PDT) > From: Matthew Dillon <dillon@apollo.backplane.com> > Message-ID: <199907132114.OAA80781@apollo.backplane.com> > > | 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. > > 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. > I have no doubt but that you can dream up scenarios where you pander to > the laziness of programmers, and make using huge VM space with little > of it actually allocated anywhere (or ever touched) then you would indeed > need monstrous amounts of paging space, most of which is never actually > used for anything - personally I prefer to have the programmers think > a little more about the memory footprint of their data structures. Not > only does this reduce the VM footprint, it will also usually vastly > improving the paging characteristics. Most applications which simply > scatter data through a huge VM space simply stop being useable as soon > as their RSS exceeds available physical memory - that is, if they start > paging, they die (become comatose might be a better description). > A little intelligent though as to how to actually make use of the mem > resources can make a huge difference. Fine. Stay with the allocation of swap for DATA/BSS of each instance of the same program you are running. That alone is enough. -- 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?378CB26D.C0BC0DBE>