Return-Path: Received: from ADDER.SLISP.CS.CMU.EDU by G.GP.CS.CMU.EDU id aa05828; 30 Jan 95 12:51:21 EST To: ram+@cs.cmu.edu Subject: Re: [Q] Installation of CMU-LISP on an Alpha-OSF Newsgroups: comp.lang.lisp In-Reply-To: <3gbr6l$802@peaches.cs.utexas.edu> References: <3gb6t2$r51@alfa.ist.utl.pt> <3gbdpp$hqi@cantaloupe.srv.cs.cmu.edu> Organization: School of Computer Science, Carnegie Mellon Cc: Bcc: Date: Mon, 30 Jan 95 17:50:52 GMT From: ram@ADDER.SLISP.CS.CMU.EDU Sender: ram@ADDER.SLISP.CS.CMU.EDU In article <3gbr6l$802@peaches.cs.utexas.edu> you write: >Rob MacLachlan wrote: >>You need to set some parameter in the system configuration which >>tells the OS to do delayed on-demand allocation of swap space, rather >>than checking the size of allocations at request time. > >Wacky as it seems, the actual way of turning off the default eager >swap allocation strategy is to remove the link /sbin/swapdefault. > >From having wasted several days trying to get a big system up and >running under OSF/1, here are some other things that will probably >cause problems: > >o The default data segment size kernel parameters (dfldsiz and >maxdsiz) are defaultly absurdly low, so you will probably have to jack >them up. Watch out, though: The kernel config program reads them out >of the config file as 32-bit signed integers (or at least it did under >2.0), so you can't specify a data segement bigger than 2GB unless you >frob the some file (param.c, I think) by hand. > >o There is a random and also absurdly low default limit (vpagemax) on >the number of discontinuous page protection changes. This limit will >undoubtedly cause problems for any system using mprotect() to effect a >GC write barrier. (A guy from DEC asked me, "But why would you want >to do something like that?" Baker obviously isn't advertising his >work enough.) > >Here are the modified parameters I use for a machine running a big >in-memory database with a write-barrier GC: > >dfldsiz 2147483647 >maxdsiz 2147483647 >vpagemax 1099511627776 >mapentries 1024 > >I forget what problem the mapentries increase solves. > >--David Gadbois >