Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!seismo!hao!hplabs!sri-unix!chris%umcp-cs@udel-relay
From: chris%umcp-cs@udel-relay@sri-unix.UUCP
Newsgroups: net.unix-wizards
Subject: Re: 16M on 4.1bsd
Message-ID: <12050@sri-arpa.UUCP>
Date: Sat, 24-Sep-83 23:57:07 EDT
Article-I.D.: sri-arpa.12050
Posted: Sat Sep 24 23:57:07 1983
Date-Received: Thu, 29-Sep-83 23:57:31 EDT
Lines: 37

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