Initial import from FreeBSD RELENG_4:
[dragonfly.git] / share / doc / papers / sysperf / 5.t
1 .\" Copyright (c) 1985 The Regents of the University of California.
2 .\" 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 .\"     @(#)5.t 5.1 (Berkeley) 4/17/91
33 .\"
34 .ds RH Functional Extensions
35 .NH
36 Functional Extensions
37 .PP
38 Some of the facilities introduced in 4.2BSD were not completely
39 implemented.  An important part of the effort that went into
40 4.3BSD was to clean up and unify both new and old facilities.
41 .NH 2
42 Kernel Extensions
43 .PP
44 A significant effort went into improving
45 the networking part of the kernel.
46 The work consisted of fixing bugs,
47 tuning the algorithms,
48 and revamping the lowest levels of the system
49 to better handle heterogeneous network topologies.
50 .NH 3
51 Subnets, Broadcasts and Gateways
52 .PP
53 To allow sites to expand their network in an autonomous
54 and orderly fashion, subnetworks have been introduced in 4.3BSD [GADS85].
55 This facility allows sites to subdivide their local Internet address
56 space into multiple subnetwork address spaces that are visible
57 only by hosts at that site.  To off-site hosts machines on a site's
58 subnetworks appear to reside on a single network.  The routing daemon
59 has been reworked to provide routing support in this type of
60 environment.
61 .PP
62 The default Internet broadcast address is now specified with a host part
63 of all one's, rather than all zero's.
64 The broadcast address may be set at boot time on a per-interface basis.
65 .NH 3
66 Interface Addressing
67 .PP
68 The organization of network interfaces has been
69 reworked to more cleanly support multiple
70 network protocols.  Network interfaces no longer
71 contain a host's address on that network; instead
72 each interface contains a pointer to a list of addresses 
73 assigned to that interface.  This permits a single
74 interface to support, for example, Internet protocols
75 at the same time as XNS protocols.
76 .PP
77 The Address Resolution Protocol (ARP) support
78 for 10 megabyte/second Ethernet\(dg
79 .FS
80 \(dg Ethernet is a trademark of Xerox.
81 .FE
82 has been made more flexible by allowing hosts to
83 act as an ``clearing house'' for hosts that do
84 not support ARP.  In addition, system managers have
85 more control over the contents of the ARP translation
86 cache and may interactively interrogate and modify
87 the cache's contents.
88 .NH 3
89 User Control of Network Buffering
90 .PP
91 Although the system allocates reasonable default amounts of buffering
92 for most connections, certain operations such as file system dumps
93 to remote machines benefit from significant increases in buffering [Walsh84].
94 The \fIsetsockopt\fP system call has been extended to allow such requests.
95 In addition, \fIgetsockopt\fP and \fIsetsockopt\fP,
96 are now interfaced to the protocol level allowing protocol-specific
97 options to be manipulated by the user.
98 .NH 3
99 Number of File Descriptors
100 .PP
101 To allow full use of the many descriptor based services available,
102 the previous hard limit of 30 open files per process has been relaxed.
103 The changes entailed generalizing \fIselect\fP to handle arrays of 
104 32-bit words, removing the dependency on file descriptors from
105 the page table entries,
106 and limiting most of the linear scans of a process's file table.
107 The default per-process descriptor limit was raised from 20 to 64,
108 though there are no longer any hard upper limits on the number
109 of file descriptors.
110 .NH 3
111 Kernel Limits
112 .PP
113 Many internal kernel configuration limits have been increased by suitable
114 modifications to data structures.
115 The limit on physical memory has been changed from 8 megabyte to 64 megabyte,
116 and the limit of 15 mounted file systems has been changed to 255.
117 The maximum file system size has been increased to 8 gigabyte,
118 number of processes to 65536,
119 and per process size to 64 megabyte of data and 64 megabyte of stack.
120 Note that these are upper bounds,
121 the default limits for these quantities are tuned for systems
122 with 4-8 megabyte of physical memory.
123 .NH 3
124 Memory Management
125 .PP
126 The global clock page replacement algorithm used to have a single
127 hand that was used both to mark and to reclaim memory.
128 The first time that it encountered a page it would clear its reference bit.
129 If the reference bit was still clear on its next pass across the page,
130 it would reclaim the page.
131 The use of a single hand does not work well with large physical
132 memories as the time to complete a single revolution of the hand
133 can take up to a minute or more.
134 By the time the hand gets around to the marked pages,
135 the information is usually no longer pertinent.
136 During periods of sudden shortages,
137 the page daemon will not be able to find any reclaimable pages until
138 it has completed a full revolution.
139 To alleviate this problem,
140 the clock hand has been split into two separate hands.
141 The front hand clears the reference bits,
142 the back hand follows a constant number of pages behind
143 reclaiming pages that still have cleared reference bits.
144 While the code has been written to allow the distance between
145 the hands to be varied, we have not found any algorithms
146 suitable for determining how to dynamically adjust this distance.
147 .PP
148 The configuration of the virtual memory system used to require
149 a significant understanding of its operation to do such
150 simple tasks as increasing the maximum process size.
151 This process has been significantly improved so that the most
152 common configuration parameters, such as the virtual memory sizes,
153 can be specified using a single option in the configuration file.
154 Standard configurations support data and stack segments
155 of 17, 33 and 64 megabytes.
156 .NH 3
157 Signals
158 .PP
159 The 4.2BSD signal implementation would push several words
160 onto the normal run-time stack before switching to an
161 alternate signal stack.
162 The 4.3BSD implementation has been corrected so that
163 the entire signal handler's state is now pushed onto the signal stack.
164 Another limitation in the original signal implementation was
165 that it used an undocumented system call to return from signals.
166 Users could not write their own return from exceptions;
167 4.3BSD formally specifies the \fIsigreturn\fP system call.
168 .PP
169 Many existing programs depend on interrupted system calls.
170 The restartable system call semantics of 4.2BSD signals caused
171 many of these programs to break.
172 To simplify porting of programs from inferior versions of 
173 .UX
174 the \fIsigvec\fP system call has been extended so that
175 programmers may specify that system calls are not to be
176 restarted after particular signals.
177 .NH 3
178 System Logging
179 .PP
180 A system logging facility has been added
181 that sends kernel messages to the
182 syslog daemon for logging in /usr/adm/messages and possibly for 
183 printing on the system console.
184 The revised scheme for logging messages
185 eliminates the time lag in updating the messages file,
186 unifies the format of kernel messages,
187 provides a finer granularity of control over the messages
188 that get printed on the console,
189 and eliminates the degradation in response during the printing of 
190 low-priority kernel messages.
191 Recoverable system errors and common resource limitations are logged
192 using this facility.
193 Most system utilities such as init and login,
194 have been modified to log errors to syslog
195 rather than writing directly on the console.
196 .NH 3
197 Windows
198 .PP
199 The tty structure has been augmented to hold
200 information about the size
201 of an associated window or terminal.
202 These sizes can be obtained by programs such as editors that want
203 to know the size of the screen they are manipulating.
204 When these sizes are changed,
205 a new signal, SIGWINCH, is sent the current process group.
206 The editors have been modified to catch this signal and reshape
207 their view of the world, and the remote login program and server
208 now cooperate to propagate window sizes and window size changes
209 across a network.
210 Other programs and libraries such as curses that need the width
211 or height of the screen have been modified to use this facility as well.
212 .NH 3
213 Configuration of UNIBUS Devices
214 .PP
215 The UNIBUS configuration routines have been extended to allow auto-configuration
216 of dedicated UNIBUS memory held by devices.
217 The new routines simplify the configuration of memory-mapped devices
218 and correct problems occurring on reset of the UNIBUS.
219 .NH 3
220 Disk Recovery from Errors
221 .PP
222 The MASSBUS disk driver's error recovery routines have been fixed to
223 retry before correcting ECC errors, support ECC on bad-sector replacements,
224 and correctly attempt retries after earlier
225 corrective actions in the same transfer.
226 The error messages are more accurate.
227 .NH 2
228 Functional Extensions to Libraries and Utilities
229 .PP
230 Most of the changes to the utilities and libraries have been to
231 allow them to handle a more general set of problems,
232 or to handle the same set of problems more quickly.
233 .NH 3
234 Name Server
235 .PP
236 In 4.2BSD the name resolution routines (\fIgethostbyname\fP,
237 \fIgetservbyname\fP,
238 etc.) were implemented by a set of database files maintained on the
239 local machine.
240 Inconsistencies or obsolescence in these files resulted in inaccessibility of
241 hosts or services.
242 In 4.3BSD these files may be replaced by a network name server that can
243 insure a consistent view of the name space in a multimachine environment.
244 This name server operates in accordance with Internet standards
245 for service on the ARPANET [Mockapetris83].
246 .NH 3
247 System Management
248 .PP
249 A new utility, \fIrdist\fP,
250 has been provided to assist system managers in keeping
251 all their machines up to date with a consistent set of sources and binaries.
252 A master set of sources may reside on a single central machine,
253 or be distributed at (known) locations throughout the environment.
254 New versions of \fIgetty\fP, \fIinit\fP, and \fIlogin\fP
255 merge the functions of several
256 files into a single place, and allow more flexibility in the
257 startup of processes such as window managers.
258 .PP
259 The new utility \fItimed\fP keeps the time on a group of cooperating machines
260 (within a single LAN) synchronized to within 30 milliseconds.
261 It does its corrections using a new system call that changes
262 the rate of time advance without stopping or reversing the system clock.
263 It normally selects one machine to act as a master.
264 If the master dies or is partitioned, a new master is elected.
265 Other machines may participate in a purely slave role.
266 .NH 3
267 Routing
268 .PP
269 Many bugs in the routing daemon have been fixed;
270 it is considerably more robust,
271 and now understands how to properly deal with
272 subnets and point-to-point networks.
273 Its operation has been made more efficient by tuning with the use
274 of execution profiles, along with inline expansion of common operations
275 using the kernel's \fIinline\fP optimizer.
276 .NH 3
277 Compilers
278 .PP
279 The symbolic debugger \fIdbx\fP has had many new features added,
280 and all the known bugs fixed.  In addition \fIdbx\fP
281 has been extended to work with the Pascal compiler.
282 The fortran compiler \fIf77\fP has had numerous bugs fixed.
283 The C compiler has been modified so that it can, optionally,
284 generate single precision floating point instructions when operating
285 on single precision variables.