Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!rutgers!cunixf.cc.columbia.edu!alan From: alan@cunixf.cc.columbia.edu (Alan Crosswell) Newsgroups: comp.sys.encore Subject: Re: Umax 4.3 virtual memory problem Keywords: Umax, paging, cow, bug Message-ID: <1990Sep18.210722.206@cunixf.cc.columbia.edu> Date: 18 Sep 90 21:07:22 GMT References: <1479@sirius.ucs.adelaide.edu.au> Organization: Columbia University Lines: 31 In article jdarcy@encore.com (Jeff d'Arcy) writes: >gordoni@chook.adelaide.edu.au (Gordon Irlam) writes: >> "How to sell overpriced memory expansion boards." We also "discovered" that the u area is not swappable in UMAX 4.3. We ran into this when our mostly-idle 4-processor 510 ran out of process slots (at around 450 or so) since it had "only" 64M of memory. There were a lot of idle logged-in users tying up proc slots. We fixed it by accelerating our original plan to purchase more memory which we knew we would need for performance reasons. I can live with performance degradation when there's more virtual than physical memory required, but stopping dead due to a physical memory limit is silly. After all, the u and proc tables were decoupled in the original Unix design just so the large u area could be swapped since it wasn't needed for process scheduling. Again, understandable that Encore ran into problems parallelizing a non-parallel kernel design, but some things need to get fixed -- even if it means scrapping the 4.3 kernel and dropping Mach in instead. After all, not much point in supporting two kernels that both provide a 4.3 system call interface. I'm not too upset since the future does offer better software for this platform -- namely OSF/1 and/or Encore Mach. Hopefully OSF/1 will become a product soon.... Of course Encore Mach is now. So, I'm not writing off the Multimax -- it's still a neat machine and there is a better VM implementation already running on it. Alan Crosswell Center for Computing Activities Columbia University