chris@umcp-cs.UUCP (02/16/84)
I thought my reply might be of general interest (especially to those interested in increasing the maximum size of a process under 4.1). [Begin forwarded message] From: Chris Torek <chris@umcp-cs> Subject: Re: panic vmdrum NDMAP To: messick@oregon-state Sounds like someone changed DMMIN, DMMAX, DMTEXT, the allocation algorithm, and/or the maximum process size, without changing NDMAP. The swap area is broken up into a bunch of little fragments with NDMAP "starting points". DMMIN is normally 32, DMMAX 1024; allocation goes like this: # size total size (sizes in ``core clicks'' = 512 bytes) -- ---- ----- ---- 0 32 32 1 64 96 2 128 224 3 256 480 4 512 992 5 1024 2016 6 1024 3040 7 1024 4064 8 1024 5088 9 1024 6112 10 1024 7136 11 1024 8160 12 1024 9184 13 1024 10208 14 1024 11232 15 1024 12256 [Pardon minor arith mistakes if any - I didn't recheck --ACT] Now, half of 12256 is 6128, which is the maximum size in Kbytes of a process under standard 4.1. Whenever a process grows, one of these little areas is allocated, from the head of the list at the appropriate subscript. If you have a different DMMIN, DMMAX, DMTEXT (DMMAX for text pages), growth algorithm, or maximum process size, then you need a different number of elements. Simple, eh? (Not by a long shot.) Wait'll you hear about the bug in the swap allocation...: Turns out that the code which computes the total space available for swapping rounds UP! Most of the swap*.c config files for 4.1 have a swap size of 33440 512-byte sectors. This doesn't fit evenly into the divisions set up in vmdrum.c. The result is that if someone tries to use all 1024 core clicks in the last segment (fairly rare), the disk driver notices that the read or write request extends past those 33440 sectors and sets B_ERROR, which later causes the machine to crash with ``panic: hard I/O error in swap''. A fix was posted a while ago, and I can send you a copy if you need it. Hope this helps, Chris [End forwarded message] -- In-Real-Life: Chris Torek, Univ of MD Comp Sci UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris.umcp-cs@CSNet-Relay