🚀 go-pugleaf

In article <347@mohawk.cs.utexas.edu> bryan@cs.utexas.edu (Bryan Bayerdorffer @ Wit's End) writes:

>       Yeah, I thought of posting the same response to Matt's
>article, but there is a problem.  Neglecting chip RAM, the reason a
>task needs physical memory is to guarantee fixed execution time for
>instructions, and for calls to AllocMem.  Now, you can lock the page
>frames occupied by the code at load time, but if you allow AllocMem
>to kick out a VM page, and the page is dirty, then you have to wait
>for the pager to run and write the page out to disk.  I can think of
>a couple of solutions to this, but none are much better than
>statically partitioning memory.  Of course, if you don't run any
>real-time programs, then the idea remains elegant, and I'm glad I had
>it first. :-)

Thpppt.  I had it first. :-)

Seriously, you could help that situation by reserving a set amount of
free real RAM that should be available at any given time.  It could
act as a buffer so the pager could free more pages while the program
merrily goes and uses the memory it allocated.  Alternatively, (or
conjunctively, or something) you could have a maximum number of
"dirty" pages the pager may have...  and allow it to use as much
memory as is available for read-only pages, which can be (almost)
instantly flushed.  Basically, this comes down to minimum clean free
pages, but without necessarily wasting them...

That's the idea, anyhow.

Deven
--
shadow@[128.113.10.2]   <shadow@pawl.rpi.edu> Deven T. Corzine (518) 272-5847
shadow@[128.113.10.201] <shadow@acm.rpi.edu>  2346 15th St.    Pi-Rho America
deven@rpitsmts.bitnet   <userfxb6@rpitsmts>   Troy, NY 12180-2306  <<tionen>>
"Simple things should be simple and complex things should be possible." - A.K.