Subject: A new user's comments, part 4
To: None <pk@cs.few.eur.nl>
From: Scott L. Burson <gyro@zeta-soft.com>
List: port-sparc
Date: 06/07/1995 14:21:29
From: Paul Kranenburg <pk@cs.few.eur.nl>
Date: Mon, 5 Jun 1995 14:11:19 +0200 (MET DST)
> No, alas. `unlimit' expanded the data size limit from 16MB to 64MB, big
> enough to start Lisp (but not big enough in the long run -- is this 64MB a
> kernel parameter somewhere?). However, when started Lisp now exits
There's this "#define MAXDSIZ" in vmparam.h which enforces the 64MB limit.
You can try to increase it a bit and see what happens (I never tried it).
Ah! Thanks!!
Well, I just grepped around for it and couldn't see any indication that
raising it would be harmful, except that the following in `vm/vm_mmap.c'
suggests that it wouldn't be a good idea to increase it all the way to the
sun4c limit of 512MB:
/*
* XXX for non-fixed mappings where no hint is provided or
* the hint would fall in the potential heap space,
* place it after the end of the largest possible heap.
*
* There should really be a pmap call to determine a reasonable
* location. (To avoid VA cache alias problems, for example!)
*/
else if (addr < round_page(p->p_vmspace->vm_daddr + MAXDSIZ))
addr = round_page(p->p_vmspace->vm_daddr + MAXDSIZ);
To my surprise, I didn't find any reason to believe that increasing MAXDSIZ
would result in a larger or slower kernel. So there seems to be little reason
to keep this limit (and presumably also the other limits in `vmparam.h',
though I haven't grepped for them) much less than the hardware maximum.
-- Scott