Date: Tue, 13 Jul 1999 15:33:40 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Neil A. Carson" <neil@causality.com> Cc: Jason Thorpe <thorpej@nas.nasa.gov>, freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) Message-ID: <199907132233.PAA81393@apollo.backplane.com> References: <199907132130.OAA24167@lestat.nas.nasa.gov> <378BB9DB.F1CE6978@causality.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:Jason Thorpe wrote:
:>
:> On Tue, 13 Jul 1999 14:14:52 -0700 (PDT)
:> Matthew Dillon <dillon@apollo.backplane.com> wrote:
:>
:> > 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.
:
:> from userspace. That way, my correctly written program can take appropriate
:> action (like, say, invoke its type-stable memory pool garbage collector, and
:> try again).
:>
:> Right now, BSD doesn't do this, and that makes creating a truly reliable
:> system *very hard*.
:
:John Dyson changed NCOS (which runs on swapless systems) for a behaviour
:whereby memory was accounted much more strictly and monitored by a
:background process on the desktop. When the 'statistical conditions'
:(which take partially into account memory that could be reaped by the
:pagedaemon, etc) get to a 'yellow' state, the desktop monitor asks
:applications to close themselves. Especially with ref to JVMs etc, this
:took a very long time to get right.
:
: Neil
This is an excellent example of a solution. Another example would be
to implement your own memory management subsystem... that is, your own
shared library which keeps track of memory allocations on a global
basis. I could do one in about an hour. One simply mmap()'s a 4K
shared page into every process running on the system and then keeps
track of memory allocations on a process-by-process basis, summing it
globally within the structure to get an idea about overall memory
use. The library can then perform garbage collection and notification
when the total approaches the danger level and it can do it almost
entirely independantly of the kernel's own memory management & paging.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?199907132233.PAA81393>