Date: Wed, 14 Jul 1999 12:49:45 -0700 From: jnemeth@victoria.tc.ca (John Nemeth) To: "Daniel C. Sobral" <dcs@newsguy.com> Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) Message-ID: <199907141949.MAA11413@vtn1.victoria.tc.ca> In-Reply-To: "Daniel C. Sobral" <dcs@newsguy.com> "Re: Replacement for grep(1) (part 2)" (Jul 15, 12:53am)
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 15, 12:53am, "Daniel C. Sobral" wrote:
} Robert Elz wrote:
} >
} > From: Matthew Dillon <dillon@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.
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.
} > 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.
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.
}-- End of excerpt from "Daniel C. Sobral"
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?199907141949.MAA11413>