Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!wuarchive!mit-eddie!uw-beaver!milton!sumax!polari!rwing!nanook
From: nanook@rwing.UUCP (Robert Dinse)
Newsgroups: comp.sys.tandy
Subject: Re: tandy 16B and 16 bit compress (thanks and another Q)
Summary: Memory Idle and Maxmem
Message-ID: <204@rwing.UUCP>
Date: 21 Dec 90 05:55:05 GMT
References: <1990Dec12.003253.18391@csis.dit.csiro.au> <1990Dec18.225202.4693@csis.dit.csiro.au>
Organization: Totally Unorganized
Lines: 17

In article <1990Dec18.225202.4693@csis.dit.csiro.au>, ken@csis.dit.csiro.au (Ken Yap) writes:

> Ironic note: I see no evidence that the previous owner knew about this
> limit so he never used all that memory. Imagine all those memory cells
> idle.  :-)

     Maxmem is a per-process limit not a total limit on system memory
utilization. At any one time you will have more than one process in memory
plus the kernal occupies some space so those memory cells weren't sitting
idle.

     I've been told by some Tandy guru's that Maxmem is to prevent a lock-up
condition from occuring under certain circumstances and have been advised
that it should be set to less than 1/2 total user memory, though I've had to
violate that rule grossly on my system (Maxmem = 3000k with about 3700k
user memory available (4 megs less kernal)) in order to get gcc not to core
dump. (Some gcc processes have been larger than 2 megs).