16M on 4.1bsd
chris%umcp-cs at udel-relay
chris%umcp-cs at udel-relay
Sun Sep 25 13:57:07 AEST 1983
From: Chris Torek <chris%umcp-cs at udel-relay>
From: mike.nmt at 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 at rand-relay (arpa)
mike at 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
More information about the Comp.unix.wizards
mailing list