🚀 go-pugleaf

In article <8905181705.AA08260@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes:

	   Hey Hey!  A guy can make mistakes!  You are right of course... all
   (or most) of real memory should be under VM but have the ability to 'lock'
   pages into memory as has been mentioned.

Well, at least you'll admit to them...  :-)

	   The only problem is that AllocMem() requests are normally quite
   small... much smaller than a page, so management becomes more difficult if
   all of real memory is in VM.  Still, it isn't much of a problem.

Sure, they're small, but that needn't pose a problem.  Simply force
the pager to free pages (as necessary) enough to satisfy the request.
if there's no memory left, and 8 bytes are allocated, then it should
free a (presumably) 512 byte page from VM and allocate 8 bytes leaving
the other 504 still free.  [this is ignoring system overhead,
clearly.]  Of course, it should try to free pages which would merge
with the already-free memory for efficiency.  [I consider memory
efficiency to be more important than speed efficiency, for the most
part.]

           On this MEMF_PHYSICAL vs MEMF_VIRTUAL bit.  Sure MEMF_PHYSICAL
   is a nice way to say 'I want memory and it should be locked', and I'd
   much rather have that than MEMF_VIRTUAL (which says 'I want this
   memory to be pagable'), but really the only way to guarentee upward
   compatibility is to make physical the default and MEMF_VIRTUAL the
   exception.  Thus have a MEMF_VIRTUAL AllocMem() flag and not a
   MEMF_PHYSICAL flag.

It helps guarantee compatibility, but would tend to discourage its
use.  If people have to go out of their way to lock the memory
allocated into real memory, then they're not normally likely to do it
unless there's a need to.  Similarly, people aren't likely to add an
MEMF_VIRTUAL flag unless there's particular reason for it.
Particularly susceptible would be small programs and most anything
written by someone who has no MMU and does not expect to get one.

Keep in mind that many, many programmers are lazy.  Most, to be sure.
It's hard enough to get them to stay within system guidelines well
enough not to crash the entire machine.  Consider the issue of screen
sizes...  people who use morerows (such as myself) will often get
tired of resizing new windows that applications create (such as, say,
DME...  :-) to the real screen size instead of the program's assumed
screen size.  The programmer could include code to check the actual
size of the screen, yet usually does not.  Particularly if the
programmer doesn't use anything but a 640x200 screen.  They often
don't support well any screen size approaching the possible 704x440 or
so you can get.

With that aside aside, you can expect that many programmers will
ignore a MEMF_VIRTUAL flag, leaving people WITH an MMU in trouble.  I
suggest that a preferable solution would be to add a MEMF_LOCKED
(and/or MEMF_PHYSICAL) flag, and make VM the default unless explicitly
requested locked memory is allocated.  For compatibility, perhaps the
best solution would be the ability to mark a particular task as being
locked in memory, so everything it allocates (as well as the code and
data) will automatically have the MEMF_LOCKED flag set.  And, of
course, there would need to be an easy way to run an old program
locked in memory.  [a utility program, probably, or maybe a
modification of the loader format?]  This way, you could get unchanged
operation (at slightly more effort) on those few programs where it's
likely to *really* matter, (probably would need some trial and error)
and other programs could take advantage of virtual memory without
having to be recompiled or modified.

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.