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