Add unifdef(1) to the bootstrap-tools.
[dragonfly.git] / usr.sbin / config / SMM.doc / d.t
blobdb9ab80116c5a49bbd2c0b57f36d625c07a640c4
1 .\" Copyright (c) 1983, 1993
2 .\"     The Regents of the University of California.  All rights reserved.
3 .\"
4 .\" Redistribution and use in source and binary forms, with or without
5 .\" modification, are permitted provided that the following conditions
6 .\" are met:
7 .\" 1. Redistributions of source code must retain the above copyright
8 .\"    notice, this list of conditions and the following disclaimer.
9 .\" 2. Redistributions in binary form must reproduce the above copyright
10 .\"    notice, this list of conditions and the following disclaimer in the
11 .\"    documentation and/or other materials provided with the distribution.
12 .\" 3. All advertising materials mentioning features or use of this software
13 .\"    must display the following acknowledgement:
14 .\"     This product includes software developed by the University of
15 .\"     California, Berkeley and its contributors.
16 .\" 4. Neither the name of the University nor the names of its contributors
17 .\"    may be used to endorse or promote products derived from this software
18 .\"    without specific prior written permission.
19 .\"
20 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
21 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
22 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
23 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
24 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
25 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
26 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
27 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
28 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
29 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
30 .\" SUCH DAMAGE.
31 .\"
32 .\"     @(#)d.t 8.1 (Berkeley) 6/8/93
33 .\"
34 .\".ds RH "Data Structure Sizing Rules
35 .bp
36 .LG
38 .ce
39 APPENDIX D. VAX KERNEL DATA STRUCTURE SIZING RULES
40 .sp
42 .NL
43 .PP
44 Certain system data structures are sized at compile time
45 according to the maximum number of simultaneous users expected,
46 while others are calculated at boot time based on the
47 physical resources present, e.g. memory.  This appendix lists
48 both sets of rules and also includes some hints on changing
49 built-in limitations on certain data structures.
50 .SH
51 Compile time rules
52 .PP
53 The file \fI/sys/conf\|/param.c\fP contains the definitions of
54 almost all data structures sized at compile time.  This file
55 is copied into the directory of each configured system to allow
56 configuration-dependent rules and values to be maintained.
57 (Each copy normally depends on the copy in /sys/conf,
58 and global modifications cause the file to be recopied unless
59 the makefile is modified.)
60 The rules implied by its contents are summarized below (here
61 MAXUSERS refers to the value defined in the configuration file
62 in the ``maxusers'' rule).
63 Most limits are computed at compile time and stored in global variables
64 for use by other modules; they may generally be patched in the system
65 binary image before rebooting to test new values.
66 .IP \fBnproc\fP
67 .br
68 The maximum number of processes which may be running at any time.
69 It is referred to in other calculations as NPROC and is defined to be
70 .DS
71 20 + 8 * MAXUSERS
72 .DE
73 .IP \fBntext\fP
74 .br
75 The maximum number of active shared text segments.
76 The constant is intended to allow for network servers and common commands
77 that remain in the table.
78 It is defined as
79 .DS
80 36 + MAXUSERS.
81 .DE
82 .IP \fBninode\fP
83 .br
84 The maximum number of files in the file system which may be
85 active at any time.  This includes files in use by users, as 
86 well as directory files being read or written by the system
87 and files associated with bound sockets in the UNIX IPC domain.
88 It is defined as
89 .DS
90 (NPROC + 16 + MAXUSERS) + 32
91 .DE
92 .IP \fBnfile\fP
93 .br
94 The number of ``file table'' structures.  One file
95 table structure is used for each open, unshared, file descriptor.
96 Multiple file descriptors may reference a single file table
97 entry when they are created through a \fIdup\fP call, or as the
98 result of a \fIfork\fP.  This is defined to be
99 .DS
100 16 * (NPROC + 16 + MAXUSERS) / 10 + 32
102 .IP \fBncallout\fP
104 The number of ``callout'' structures.  One callout
105 structure is used per internal system event handled with
106 a timeout.  Timeouts are used for terminal delays,
107 watchdog routines in device drivers, protocol timeout processing, etc.
108 This is defined as
110 16 + NPROC
112 .IP \fBnclist\fP
114 The number of ``c-list'' structures.  C-list structures are
115 used in terminal I/O, and currently each holds 60 characters.
116 Their number is defined as
118 60 + 12 * MAXUSERS
120 .IP \fBnmbclusters\fP
122 The maximum number of pages which may be allocated by the network.  
123 This is defined as 256 (a quarter megabyte of memory) in /sys/h/mbuf.h.
124 In practice, the network rarely uses this much memory.  It starts off
125 by allocating 8 kilobytes of memory, then requesting more as 
126 required.  This value represents an upper bound.
127 .IP \fBnquota\fP
129 The number of ``quota'' structures allocated.  Quota structures
130 are present only when disc quotas are configured in the system.  One
131 quota structure is kept per user.  This is defined to be
133 (MAXUSERS * 9) / 7 + 3
135 .IP \fBndquot\fP
137 The number of ``dquot'' structures allocated.  Dquot structures
138 are present only when disc quotas are configured in the system.
139 One dquot structure is required per user, per active file system quota.
140 That is, when a user manipulates a file on a file system on which
141 quotas are enabled, the information regarding the user's quotas on
142 that file system must be in-core.  This information is cached, so
143 that not all information must be present in-core all the time.
144 This is defined as
146 NINODE + (MAXUSERS * NMOUNT) / 4
148 where NMOUNT is the maximum number of mountable file systems.
150 In addition to the above values, the system page tables (used to
151 map virtual memory in the kernel's address space) are sized at
152 compile time by the SYSPTSIZE definition in the file /sys/vax/vmparam.h.
153 This is defined to be
155 20 + MAXUSERS
157 pages of page tables. 
158 Its definition affects
159 the size of many data structures allocated at boot time because
160 it constrains the amount of virtual memory which may be addressed
161 by the running system.  This is often the limiting factor
162 in the size of the buffer cache, in which case a message is printed
163 when the system configures at boot time.
165 Run-time calculations
167 The most important data structures sized at run-time are those used in
168 the buffer cache.  Allocation is done by allocating physical memory
169 (and system virtual memory) immediately after the system
170 has been started up; look in the file /sys/vax/machdep.c.
171 The amount of physical memory which may be allocated to the buffer
172 cache is constrained by the size of the system page tables, among
173 other things.  While the system may calculate
174 a large amount of memory to be allocated to the buffer cache,
175 if the system page
176 table is too small to map this physical
177 memory into the virtual address space
178 of the system, only as much as can be mapped will be used.
180 The buffer cache is comprised of a number of ``buffer headers''
181 and a pool of pages attached to these headers.  Buffer headers
182 are divided into two categories: those used for swapping and
183 paging, and those used for normal file I/O.  The system tries
184 to allocate 10% of the first two megabytes and 5% of the remaining
185 available physical memory for the buffer
186 cache (where \fIavailable\fP does not count that space occupied by
187 the system's text and data segments).  If this results in fewer
188 than 16 pages of memory allocated, then 16 pages are allocated.
189 This value is kept in the initialized variable \fIbufpages\fP
190 so that it may be patched in the binary image (to allow tuning
191 without recompiling the system),
192 or the default may be overridden with a configuration-file option.
193 For example, the option \fBoptions BUFPAGES="3200"\fP
194 causes 3200 pages (3.2M bytes) to be used by the buffer cache.
195 A sufficient number of file I/O buffer headers are then allocated
196 to allow each to hold 2 pages each.
197 Each buffer maps 8K bytes.
198 If the number of buffer pages is larger than can be mapped
199 by the buffer headers, the number of pages is reduced.
200 The number of buffer headers allocated
201 is stored in the global variable \fInbuf\fP,
202 which may be patched before the system is booted.
203 The system option \fBoptions NBUF="1000"\fP forces the allocation
204 of 1000 buffer headers.
205 Half as many swap I/O buffer headers as file I/O buffers
206 are allocated,
207 but no more than 256.
209 System size limitations
211 As distributed, the sum of the virtual sizes of the core-resident
212 processes is limited to 256M bytes.  The size of the text
213 segment of a single process is currently limited to 6M bytes.
214 It may be increased to no greater than the data segment size limit
215 (see below) by redefining MAXTSIZ.
216 This may be done with a configuration file option,
217 e.g. \fBoptions MAXTSIZ="(10*1024*1024)"\fP
218 to set the limit to 10 million bytes.
219 Other per-process limits discussed here may be changed with similar options
220 with names given in parentheses.
221 Soft, user-changeable limits are set to 512K bytes for stack (DFLSSIZ)
222 and 6M bytes for the data segment (DFLDSIZ) by default;
223 these may be increased up to the hard limit
224 with the \fIsetrlimit\fP\|(2) system call.
225 The data and stack segment size hard limits are set by a system configuration
226 option to one of 17M, 33M or 64M bytes.
227 One of these sizes is chosen based on the definition of MAXDSIZ;
228 with no option, the limit is 17M bytes; with an option
229 \fBoptions MAXDSIZ="(32*1024*1024)"\fP (or any value between 17M and 33M),
230 the limit is increased to 33M bytes, and values larger than 33M
231 result in a limit of 64M bytes.
232 You must be careful in doing this that you have adequate paging space.
233 As normally configured , the system has 16M or 32M bytes per paging area,
234 depending on disk size.
235 The best way to get more space is to provide multiple, thereby
236 interleaved, paging areas.
237 Increasing the virtual memory limits results in interleaving of
238 swap space in larger sections (from 500K bytes to 1M or 2M bytes).
240 By default, the virtual memory system allocates enough memory
241 for system page tables mapping user page tables
242 to allow 256 megabytes of simultaneous active virtual memory.
243 That is, the sum of the virtual memory sizes of all (completely- or partially-)
244 resident processes can not exceed this limit.
245 If the limit is exceeded, some process(es) must be swapped out.
246 To increase the amount of resident virtual space possible,
247 you can alter the constant USRPTSIZE (in
248 /sys/vax/vmparam.h).
249 Each page of system page tables allows 8 megabytes of user virtual memory.
251 Because the file system block numbers are stored in
252 page table \fIpg_blkno\fP
253 entries, the maximum size of a file system is limited to
254 2^24 1024 byte blocks.  Thus no file system can be larger than 8 gigabytes.
256 The number of mountable file systems is set at 20 by the definition
257 of NMOUNT in /sys/h/param.h.
258 This should be sufficient; if not, the value can be increased up to 255.
259 If you have many disks, it makes sense to make some of
260 them single file systems, and the paging areas don't count in this total.
262 The limit to the number of files that a process may have open simultaneously
263 is set to 64.
264 This limit is set by the NOFILE definition in /sys/h/param.h.
265 It may be increased arbitrarily, with the caveat that the user structure
266 expands by 5 bytes for each file, and thus UPAGES (/sys/vax/machparam.h)
267 must be increased accordingly.
269 The amount of physical memory is currently limited to 64 Mb
270 by the size of the index fields in the core-map (/sys/h/cmap.h).
271 The limit may be increased by following instructions in that file
272 to enlarge those fields.