On Wed, Dec 01, 1999 at 05:51:10PM -0800, Phil Nelson wrote:
> 
> >What platform? Solaris, Linux, NetBSD? Did you map more RVM data than
> >physically available memory?
> 
> Sorry I didn't answer all your questions ...
> 
> a) NetBSD 1.4.1
> b) real mem  16M
> c) RVM data 130M

Phil wrote earlier:
> (RVM data size, 266532, 133Mhz pentium ...)

But with 16M of memory you would have brought a linux-2.0 box to it's
knees. NetBSD doesn't suffer (as much?) from the double caching. Once we
hit the swap on linux 2.0 (possibly even 2.2), there are copies of the
same data floating around in the buffercache, the pagecache, and the
swapcache. Or something like that. That slows a server down to a crawl.

I just rebooted by laptop into 16MB, and started a server.

Linux-2.2.13, Pentium 166, 16MB memory, 130MB rvm data
(anonymous mapping)

21:09:30 Resource limit on data size are set to 2147483647
...
21:09:30 Setting Rvm Truncate threshold to 5. 		(start of mapping)
21:10:50 Partition /vicepa:...				(end of mapping)
21:11:07 File Server started ...

Total startup time about 97 seconds, and my processor is faster than
yours... I almost can't wait to try this with the private mappings.

> USER       PID %CPU %MEM   VSZ  RSS TT  STAT STARTED       TIME COMMAND
> root      2118  0.0 13.8  3624 2200 ??  S<s   3:19PM    0:15.61 codasrv -mappr

Ok, this doesn't seem to account for the 130 megs of memory mapped RVM
in the process. I've got:

USER    PID %CPU %MEM    VSZ  RSS TT STAT STARTED TIME COMMAND
root    534  2.9 64.8 121572 9604 ?  S <  21:09	  0:07 codasrv -sa 4 -t 1000...

> >Did the rvm_basher turn up any more problems?
> Just that one ... and I haven't figured out the problem.  It happens
> with anonymous and private mappings.  I'll look into it furthur.

It looked to me like it was trying to commit a larger transaction than
could be fitted in the log. And failing on anonymous mappings could be
an indication towards a bad parameter somewhere.

Jan