/share/doc/papers/sysperf/5.t

https://bitbucket.org/freebsd/freebsd-head/ · Raku · 287 lines · 287 code · 0 blank · 0 comment · 8 complexity · d2a06d0c50142f9c78e7cae270732404 MD5 · raw file

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