[net.unix-wizards] 16M on 4.1bsd

chris%umcp-cs%udel-relay@sri-unix.UUCP (09/14/83)

From:  Chris Torek <chris%umcp-cs@udel-relay>

(This may be of general interest...  I thought I probably should copy
 it to the Unix-Wizards list.)

 Date:     13 Sep 83 18:49:37 EDT  (Tue)
 From:     Chris Torek <chris@umcp-cs>
 Subject:  16M on 4.1bsd
 To:       negaard@aerospace

A quickie answer off the top of my head:  try increasing the space
reserved for the system page table map (called, I think, "Sysmap").
I just looked at machdep.c and locore.s -- the size is determined
by the #define'd constant SYSPTSIZE in ../h/vmparam.h (note the
comment about "this should be computed at boot time"!).  To map 16M
you need, I think, twice as many pt entries as they allocated.
(How about that, I was right, it's "Sysmap" and "Sysbase".)

The black book (or is it the red book?  Well, one of either the
Architecture Manual or the Hardware Handbook) has more info on
VM and pte allocation, if you need it.

Chris

chris%umcp-cs@udel-relay@sri-unix.UUCP (09/25/83)

From:  Chris Torek <chris%umcp-cs@udel-relay>

	From: mike.nmt@Rand-Relay

	Something else you need to consider:

	Cmap structures (one allocated for every cluster of available memory)
	are linked together when free via the c_next and c_prev fields (also
	via c_hlink when cluster is associated with a shared-text block).
	These fields contain the index of another cmap structure.  Since these
	fields are only 13 bits, we can only have up to 8192 clusters of memory.
	With the distributed CLSIZE, this means only 8Mb of memory.  In order
	to handle 16Mb of memory CLSIZE would have to be increased to 4 giving
	you 2048 byte clusters.   A side-effect of this is that the filesystem
	block size would also become 2048, implying that you would have to
	remake all filesystems.

	An alternative would be to increase the size of the c_next, c_prev and
	c_hlink fields but I don't know what other side-effects would result
	from such a change.

			Mike Hibler
			Computer Science Dept.
			New Mexico Tech
			Socorro, NM  87801
			ucbvax!unmvax!nmtvax!mike	(uucp)
			mike.nmt@rand-relay		(arpa)
			mike@nmt			(CSnet)

You're right, and I forgot about that one.  The simplest thing is to
just increase the three fields.  The only trouble that might cause
is that you may need more memory for cmap entries.  I think that's not
a problem 'cause the allocation uses sizeof(struct cmap) instead of
some wired number.  Berkeley was just trying to make everything fit
in less memory -- which, if you have 16M, is probably not too important.

Chris