1 .\" Copyright (c) 1985 The Regents of the University of California.
2 .\" All rights reserved.
4 .\" Redistribution and use in source and binary forms, with or without
5 .\" modification, are permitted provided that the following conditions
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.
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
32 .\" @(#)3.t 5.1 (Berkeley) 4/17/91
34 .ds RH Results of our observations
36 Results of our observations
38 When 4.2BSD was first installed on several large timesharing systems
39 the degradation in performance was significant.
40 Informal measurements showed 4.2BSD providing 80% of the throughput
41 of 4.1BSD (based on load averages observed under a normal timesharing load).
42 Many of the initial problems found were because of programs that were
43 not part of 4.1BSD. Using the techniques described in the previous
44 section and standard process profiling several problems were identified.
45 Later work concentrated on the operation of the kernel itself.
46 In this section we discuss the problems uncovered; in the next
47 section we describe the changes made to the system.
54 The mail system was the first culprit identified as a major
55 contributor to the degradation in system performance.
56 At Lucasfilm the mail system is heavily used
57 on one machine, a VAX-11/780 with eight megabytes of memory.\**
59 \** During part of these observations the machine had only four
63 traffic is usually between users on the same machine and ranges from
64 person-to-person telephone messages to per-organization distribution
65 lists. After conversion to 4.2BSD, it was
66 immediately noticed that mail to distribution lists of 20 or more people
67 caused the system load to jump by anywhere from 3 to 6 points.
68 The number of processes spawned by the \fIsendmail\fP program and
69 the messages sent from \fIsendmail\fP to the system logging
70 process, \fIsyslog\fP, generated significant load both from their
71 execution and their interference with basic system operation. The
72 number of context switches and disk transfers often doubled while
73 \fIsendmail\fP operated; the system call rate jumped dramatically.
74 System accounting information consistently
75 showed \fIsendmail\fP as the top cpu user on the system.
79 The network services provided in 4.2BSD add new capabilities to the system,
80 but are not without cost. The system uses one daemon process to accept
81 requests for each network service provided. The presence of many
82 such daemons increases the numbers of active processes and files,
83 and requires a larger configuration to support the same number of users.
84 The overhead of the routing and status updates can consume
85 several percent of the cpu.
86 Remote logins and shells incur more overhead
87 than their local equivalents.
88 For example, a remote login uses three processes and a
89 pseudo-terminal handler in addition to the local hardware terminal
90 handler. When using a screen editor, sending and echoing a single
91 character involves four processes on two machines.
92 The additional processes, context switching, network traffic, and
93 terminal handler overhead can roughly triple the load presented by one
98 To measure the costs of various functions in the kernel,
99 a profiling system was run for a 17 hour
100 period on one of our general timesharing machines.
101 While this is not as reproducible as a synthetic workload,
102 it certainly represents a realistic test.
103 This test was run on several occasions over a three month period.
104 Despite the long period of time that elapsed
105 between the test runs the shape of the profiles,
106 as measured by the number of times each system call
107 entry point was called, were remarkably similar.
109 These profiles turned up several bottlenecks that are
110 discussed in the next section.
111 Several of these were new to 4.2BSD,
112 but most were caused by overloading of mechanisms
113 which worked acceptably well in previous BSD systems.
114 The general conclusion from our measurements was that
115 the ratio of user to system time had increased from
116 45% system / 55% user in 4.1BSD to 57% system / 43% user
119 Micro-operation benchmarks
121 To compare certain basic system operations
122 between 4.1BSD and 4.2BSD a suite of benchmark
123 programs was constructed and run on a VAX-11/750 with 4.5 megabytes
124 of physical memory and two disks on a MASSBUS controller.
125 Tests were run with the machine operating in single user mode
126 under both 4.1BSD and 4.2BSD. Paging was localized to the drive
127 where the root file system was located.
129 The benchmark programs were modeled after the Kashtan benchmarks,
130 [Kashtan80], with identical sources compiled under each system.
131 The programs and their intended purpose are described briefly
132 before the presentation of the results. The benchmark scripts
133 were run twice with the results shown as the average of
135 The source code for each program and the shell scripts used during
136 the benchmarks are included in the Appendix.
138 The set of tests shown in Table 1 was concerned with
139 system operations other than paging. The intent of most
140 benchmarks is clear. The result of running \fIsignocsw\fP is
141 deducted from the \fIcsw\fP benchmark to calculate the context
142 switch overhead. The \fIexec\fP tests use two different jobs to gauge
143 the cost of overlaying a larger program with a smaller one
145 ``null job'' and ``big job'' differ solely in the size of their data
146 segments, 1 kilobyte versus 256 kilobytes. In both cases the
147 text segment of the parent is larger than that of the child.\**
149 \** These tests should also have measured the cost of expanding the
150 text segment; unfortunately time did not permit running additional tests.
152 All programs were compiled into the default load format that causes
153 the text segment to be demand paged out of the file system and shared
162 syscall perform 100,000 \fIgetpid\fP system calls
163 csw perform 10,000 context switches using signals
164 signocsw send 10,000 signals to yourself
165 pipeself4 send 10,000 4-byte messages to yourself
166 pipeself512 send 10,000 512-byte messages to yourself
167 pipediscard4 send 10,000 4-byte messages to child who discards
168 pipediscard512 send 10,000 512-byte messages to child who discards
169 pipeback4 exchange 10,000 4-byte messages with child
170 pipeback512 exchange 10,000 512-byte messages with child
171 forks0 fork-exit-wait 1,000 times
172 forks1k sbrk(1024), fault page, fork-exit-wait 1,000 times
173 forks100k sbrk(102400), fault pages, fork-exit-wait 1,000 times
174 vforks0 vfork-exit-wait 1,000 times
175 vforks1k sbrk(1024), fault page, vfork-exit-wait 1,000 times
176 vforks100k sbrk(102400), fault pages, vfork-exit-wait 1,000 times
177 execs0null fork-exec ``null job''-exit-wait 1,000 times
178 execs0null (1K env) execs0null above, with 1K environment added
179 execs1knull sbrk(1024), fault page, fork-exec ``null job''-exit-wait 1,000 times
180 execs1knull (1K env) execs1knull above, with 1K environment added
181 execs100knull sbrk(102400), fault pages, fork-exec ``null job''-exit-wait 1,000 times
182 vexecs0null vfork-exec ``null job''-exit-wait 1,000 times
183 vexecs1knull sbrk(1024), fault page, vfork-exec ``null job''-exit-wait 1,000 times
184 vexecs100knull sbrk(102400), fault pages, vfork-exec ``null job''-exit-wait 1,000 times
185 execs0big fork-exec ``big job''-exit-wait 1,000 times
186 execs1kbig sbrk(1024), fault page, fork-exec ``big job''-exit-wait 1,000 times
187 execs100kbig sbrk(102400), fault pages, fork-exec ``big job''-exit-wait 1,000 times
188 vexecs0big vfork-exec ``big job''-exit-wait 1,000 times
189 vexecs1kbig sbrk(1024), fault pages, vfork-exec ``big job''-exit-wait 1,000 times
190 vexecs100kbig sbrk(102400), fault pages, vfork-exec ``big job''-exit-wait 1,000 times
193 Table 1. Kernel Benchmark programs.
197 The results of these tests are shown in Table 2. If the 4.1BSD results
198 are scaled to reflect their being run on a VAX-11/750, they
199 correspond closely to those found in [Joy80].\**
201 \** We assume that a VAX-11/750 runs at 60% of the speed of a VAX-11/780
202 (not considering floating point operations).
209 c || c s s || c s s || c s s
210 c || c s s || c s s || c s s
211 c || c | c | c || c | c | c || c | c | c
212 l || n | n | n || n | n | n || n | n | n.
213 Berkeley Software Distribution UNIX Systems
215 Test Elapsed Time User Time System Time
217 \^ 4.1 4.2 4.3 4.1 4.2 4.3 4.1 4.2 4.3
219 syscall 28.0 29.0 23.0 4.5 5.3 3.5 23.9 23.7 20.4
220 csw 45.0 60.0 45.0 3.5 4.3 3.3 19.5 25.4 19.0
221 signocsw 16.5 23.0 16.0 1.9 3.0 1.1 14.6 20.1 15.2
222 pipeself4 21.5 29.0 26.0 1.1 1.1 0.8 20.1 28.0 25.6
223 pipeself512 47.5 59.0 55.0 1.2 1.2 1.0 46.1 58.3 54.2
224 pipediscard4 32.0 42.0 36.0 3.2 3.7 3.0 15.5 18.8 15.6
225 pipediscard512 61.0 76.0 69.0 3.1 2.1 2.0 29.7 36.4 33.2
226 pipeback4 57.0 75.0 66.0 2.9 3.2 3.3 25.1 34.2 29.7
227 pipeback512 110.0 138.0 125.0 3.1 3.4 2.2 52.2 65.7 57.7
228 forks0 37.5 41.0 22.0 0.5 0.3 0.3 34.5 37.6 21.5
229 forks1k 40.0 43.0 22.0 0.4 0.3 0.3 36.0 38.8 21.6
230 forks100k 217.5 223.0 176.0 0.7 0.6 0.4 214.3 218.4 175.2
231 vforks0 34.5 37.0 22.0 0.5 0.6 0.5 27.3 28.5 17.9
232 vforks1k 35.0 37.0 22.0 0.6 0.8 0.5 27.2 28.6 17.9
233 vforks100k 35.0 37.0 22.0 0.6 0.8 0.6 27.6 28.9 17.9
234 execs0null 97.5 92.0 66.0 3.8 2.4 0.6 68.7 82.5 48.6
235 execs0null (1K env) 197.0 229.0 75.0 4.1 2.6 0.9 167.8 212.3 62.6
236 execs1knull 99.0 100.0 66.0 4.1 1.9 0.6 70.5 86.8 48.7
237 execs1knull (1K env) 199.0 230.0 75.0 4.2 2.6 0.7 170.4 214.9 62.7
238 execs100knull 283.5 278.0 216.0 4.8 2.8 1.1 251.9 269.3 202.0
239 vexecs0null 100.0 92.0 66.0 5.1 2.7 1.1 63.7 76.8 45.1
240 vexecs1knull 100.0 91.0 66.0 5.2 2.8 1.1 63.2 77.1 45.1
241 vexecs100knull 100.0 92.0 66.0 5.1 3.0 1.1 64.0 77.7 45.6
242 execs0big 129.0 201.0 101.0 4.0 3.0 1.0 102.6 153.5 92.7
243 execs1kbig 130.0 202.0 101.0 3.7 3.0 1.0 104.7 155.5 93.0
244 execs100kbig 318.0 385.0 263.0 4.8 3.1 1.1 286.6 339.1 247.9
245 vexecs0big 128.0 200.0 101.0 4.6 3.5 1.6 98.5 149.6 90.4
246 vexecs1kbig 125.0 200.0 101.0 4.7 3.5 1.3 98.9 149.3 88.6
247 vexecs100kbig 126.0 200.0 101.0 4.2 3.4 1.3 99.5 151.0 89.0
250 Table 2. Kernel Benchmark results (all times in seconds).
254 In studying the measurements we found that the basic system call
255 and context switch overhead did not change significantly
256 between 4.1BSD and 4.2BSD. The \fIsignocsw\fP results were caused by
257 the changes to the \fIsignal\fP interface, resulting
258 in an additional subroutine invocation for each call, not
259 to mention additional complexity in the system's implementation.
261 The times for the use of pipes are significantly higher under
262 4.2BSD because of their implementation on top of the interprocess
263 communication facilities. Under 4.1BSD pipes were implemented
264 without the complexity of the socket data structures and with
265 simpler code. Further, while not obviously a factor here,
266 4.2BSD pipes have less system buffer space provided them than
269 The \fIexec\fP tests shown in Table 2 were performed with 34 bytes of
270 environment information under 4.1BSD and 40 bytes under 4.2BSD.
271 To figure the cost of passing data through the environment,
272 the execs0null and execs1knull tests were rerun with
273 1065 additional bytes of data. The results are show in Table 3.
278 c || c s || c s || c s
279 c || c s || c s || c s
280 c || c | c || c | c || c | c
281 l || n | n || n | n || n | n.
282 Test Real User System
284 \^ 4.1 4.2 4.1 4.2 4.1 4.2
286 execs0null 197.0 229.0 4.1 2.6 167.8 212.3
287 execs1knull 199.0 230.0 4.2 2.6 170.4 214.9
290 Table 3. Benchmark results with ``large'' environment (all times in seconds).
293 These results show that passing argument data is significantly
294 slower than under 4.1BSD: 121 ms/byte versus 93 ms/byte. Even using
295 this factor to adjust the basic overhead of an \fIexec\fP system
296 call, this facility is more costly under 4.2BSD than under 4.1BSD.
298 Path name translation
300 The single most expensive function performed by the kernel
301 is path name translation.
302 This has been true in almost every UNIX kernel [Mosher80];
303 we find that our general time sharing systems do about
304 500,000 name translations per day.
306 Name translations became more expensive in 4.2BSD for several reasons.
307 The single most expensive addition was the symbolic link.
309 have the effect of increasing the average number of components
310 in path names to be translated.
311 As an insidious example,
312 consider the system manager that decides to change /tmp
313 to be a symbolic link to /usr/tmp.
314 A name such as /tmp/tmp1234 that previously required two component
316 now requires four component translations plus the cost of reading
317 the contents of the symbolic link.
319 The new directory format also changes the characteristics of
321 The more complex format requires more computation to determine
322 where to place new entries in a directory.
323 Conversely the additional information allows the system to only
324 look at active entries when searching,
325 hence searches of directories that had once grown large
326 but currently have few active entries are checked quickly.
327 The new format also stores the length of each name so that
328 costly string comparisons are only done on names that are the
329 same length as the name being sought.
331 The net effect of the changes is that the average time to
332 translate a path name in 4.2BSD is 24.2 milliseconds,
333 representing 40% of the time processing system calls,
334 that is 19% of the total cycles in the kernel,
335 or 11% of all cycles executed on the machine.
336 The times are shown in Table 4. We have no comparable times
337 for \fInamei\fP under 4.1 though they are certain to
338 be significantly less.
344 part time % of kernel
346 self 14.3 ms/call 11.3%
347 child 9.9 ms/call 7.9%
349 total 24.2 ms/call 19.2%
352 Table 4. Call times for \fInamei\fP in 4.2BSD.
358 Nearly 25% of the time spent in the kernel is spent in the clock
360 (This is a clear indication that to avoid sampling bias when profiling the
361 kernel with our tools
362 we need to drive them from an independent clock.)
363 These routines are responsible for implementing timeouts,
364 scheduling the processor,
365 maintaining kernel statistics,
366 and tending various hardware operations such as
367 draining the terminal input silos.
368 Only minimal work is done in the hardware clock interrupt
369 routine (at high priority), the rest is performed (at a lower priority)
370 in a software interrupt handler scheduled by the hardware interrupt
372 In the worst case, with a clock rate of 100 Hz
373 and with every hardware interrupt scheduling a software
374 interrupt, the processor must field 200 interrupts per second.
375 The overhead of simply trapping and returning
376 is 3% of the machine cycles,
377 figuring out that there is nothing to do
378 requires an additional 2%.
380 Terminal multiplexors
382 The terminal multiplexors supported by 4.2BSD have programmable receiver
383 silos that may be used in two ways.
384 With the silo disabled, each character received causes an interrupt
386 Enabling the receiver silo allows the silo to fill before
387 generating an interrupt, allowing multiple characters to be read
389 At low rates of input, received characters will not be processed
390 for some time unless the silo is emptied periodically.
391 The 4.2BSD kernel uses the input silos of each terminal multiplexor,
392 and empties each silo on each clock interrupt.
393 This allows high input rates without the cost of per-character interrupts
394 while assuring low latency.
395 However, as character input rates on most machines are usually
396 low (about 25 characters per second),
397 this can result in excessive overhead.
398 At the current clock rate of 100 Hz, a machine with 5 terminal multiplexors
399 configured makes 500 calls to the receiver interrupt routines per second.
400 In addition, to achieve acceptable input latency
401 for flow control, each clock interrupt must schedule
402 a software interrupt to run the silo draining routines.\**
404 \** It is not possible to check the input silos at
405 the time of the actual clock interrupt without modifying the terminal
406 line disciplines, as the input queues may not be in a consistent state \**.
408 \** This implies that the worst case estimate for clock processing
409 is the basic overhead for clock processing.
411 Process table management
413 In 4.2BSD there are numerous places in the kernel where a linear search
414 of the process table is performed:
416 in \fIexit\fP to locate and wakeup a process's parent;
418 in \fIwait\fP when searching for \fB\s-2ZOMBIE\s+2\fP and
419 \fB\s-2STOPPED\s+2\fP processes;
421 in \fIfork\fP when allocating a new process table slot and
422 counting the number of processes already created by a user;
424 in \fInewproc\fP, to verify
425 that a process id assigned to a new process is not currently
428 in \fIkill\fP and \fIgsignal\fP to locate all processes to
429 which a signal should be delivered;
431 in \fIschedcpu\fP when adjusting the process priorities every
434 in \fIsched\fP when locating a process to swap out and/or swap
437 These linear searches can incur significant overhead. The rule
438 for calculating the size of the process table is:
440 nproc = 20 + 8 * maxusers
442 that means a 48 user system will have a 404 slot process table.
443 With the addition of network services in 4.2BSD, as many as a dozen
444 server processes may be maintained simply to await incoming requests.
445 These servers are normally created at boot time which causes them
446 to be allocated slots near the beginning of the process table. This
447 means that process table searches under 4.2BSD are likely to take
448 significantly longer than under 4.1BSD. System profiling shows
449 that as much as 20% of the time spent in the kernel on a loaded
450 system (a VAX-11/780) can be spent in \fIschedcpu\fP and, on average,
451 5-10% of the kernel time is spent in \fIschedcpu\fP.
452 The other searches of the proc table are similarly affected.
453 This shows the system can no longer tolerate using linear searches of
456 File system buffer cache
458 The trace facilities described in section 2.3 were used
459 to gather statistics on the performance of the buffer cache.
460 We were interested in measuring the effectiveness of the
461 cache and the read-ahead policies.
462 With the file system block size in 4.2BSD four to
463 eight times that of a 4.1BSD file system, we were concerned
464 that large amounts of read-ahead might be performed without
465 being used. Also, we were interested in seeing if the
466 rules used to size the buffer cache at boot time were severely
467 affecting the overall cache operation.
469 The tracing package was run over a three hour period during
470 a peak mid-afternoon period on a VAX 11/780 with four megabytes
472 This resulted in a buffer cache containing 400 kilobytes of memory
473 spread among 50 to 200 buffers
474 (the actual number of buffers depends on the size mix of
475 disk blocks being read at any given time).
476 The pertinent configuration information is shown in Table 5.
482 Controller Drive Device File System
484 DEC MASSBUS DEC RP06 hp0d /usr
486 Emulex SC780 Fujitsu Eagle hp1a /usr/spool/news
490 Fujitsu Eagle hp2a /tmp
496 Table 5. Active file systems during buffer cache tests.
500 During the test period the load average ranged from 2 to 13
501 with an average of 5.
502 The system had no idle time, 43% user time, and 57% system time.
503 The system averaged 90 interrupts per second
504 (excluding the system clock interrupts),
505 220 system calls per second,
506 and 50 context switches per second (40 voluntary, 10 involuntary).
508 The active virtual memory (the sum of the address space sizes of
509 all jobs that have run in the previous twenty seconds)
510 over the period ranged from 2 to 6 megabytes with an average
512 There was no swapping, though the page daemon was inspecting
513 about 25 pages per second.
515 On average 250 requests to read disk blocks were initiated
517 These include read requests for file blocks made by user
518 programs as well as requests initiated by the system.
519 System reads include requests for indexing information to determine
520 where a file's next data block resides,
521 file system layout maps to allocate new data blocks,
522 and requests for directory contents needed to do path name translations.
524 On average, an 85% cache hit rate was observed for read requests.
525 Thus only 37 disk reads were initiated per second.
526 In addition, 5 read-ahead requests were made each second
527 filling about 20% of the buffer pool.
528 Despite the policies to rapidly reuse read-ahead buffers
529 that remain unclaimed, more than 90% of the read-ahead
532 These measurements showed that the buffer cache was working
533 effectively. Independent tests have also showed that the size
534 of the buffer cache may be reduced significantly on memory-poor
535 system without severe effects;
536 we have not yet tested this hypothesis [Shannon83].
540 The overhead associated with the
541 network facilities found in 4.2BSD is often
542 difficult to gauge without profiling the system.
543 This is because most input processing is performed
544 in modules scheduled with software interrupts.
545 As a result, the system time spent performing protocol
546 processing is rarely attributed to the processes that
547 really receive the data. Since the protocols supported
548 by 4.2BSD can involve significant overhead this was a serious
549 concern. Results from a profiled kernel show an average
550 of 5% of the system time is spent
551 performing network input and timer processing in our environment
552 (a 3Mb/s Ethernet with most traffic using TCP).
553 This figure can vary significantly depending on
554 the network hardware used, the average message
555 size, and whether packet reassembly is required at the network
556 layer. On one machine we profiled over a 17 hour
557 period (our gateway to the ARPANET)
558 206,000 input messages accounted for 2.4% of the system time,
559 while another 0.6% of the system time was spent performing
560 protocol timer processing.
561 This machine was configured with an ACC LH/DH IMP interface
562 and a DMA 3Mb/s Ethernet controller.
564 The performance of TCP over slower long-haul networks
565 was degraded substantially by two problems.
566 The first problem was a bug that prevented round-trip timing measurements
567 from being made, thus increasing retransmissions unnecessarily.
568 The second was a problem with the maximum segment size chosen by TCP,
569 that was well-tuned for Ethernet, but was poorly chosen for
570 the ARPANET, where it causes packet fragmentation. (The maximum
571 segment size was actually negotiated upwards to a value that
572 resulted in excessive fragmentation.)
574 When benchmarked in Ethernet environments the main memory buffer management
575 of the network subsystem presented some performance anomalies.
576 The overhead of processing small ``mbufs'' severely affected throughput for a
577 substantial range of message sizes.
578 In spite of the fact that most system ustilities made use of the throughput
579 optimal 1024 byte size, user processes faced large degradations for some
580 arbitrary sizes. This was specially true for TCP/IP transmissions [Cabrera84,
583 Virtual memory subsystem
585 We ran a set of tests intended to exercise the virtual
586 memory system under both 4.1BSD and 4.2BSD.
587 The tests are described in Table 6.
588 The test programs dynamically allocated
589 a 7.3 Megabyte array (using \fIsbrk\fP\|(2)) then referenced
590 pages in the array either: sequentially, in a purely random
591 fashion, or such that the distance between
592 successive pages accessed was randomly selected from a Gaussian
593 distribution. In the last case, successive runs were made with
594 increasing standard deviations.
602 seqpage sequentially touch pages, 10 iterations
603 seqpage-v as above, but first make \fIvadvise\fP\|(2) call
604 randpage touch random page 30,000 times
605 randpage-v as above, but first make \fIvadvise\fP call
606 gausspage.1 30,000 Gaussian accesses, standard deviation of 1
607 gausspage.10 as above, standard deviation of 10
608 gausspage.30 as above, standard deviation of 30
609 gausspage.40 as above, standard deviation of 40
610 gausspage.50 as above, standard deviation of 50
611 gausspage.60 as above, standard deviation of 60
612 gausspage.80 as above, standard deviation of 80
613 gausspage.inf as above, standard deviation of 10,000
616 Table 6. Paging benchmark programs.
620 The results in Table 7 show how the additional
622 of 4.2BSD can generate more work for the paging system.
624 the system used 0.5 of the 4.5 megabytes of physical memory
626 under 4.2BSD it used nearly 1 megabyte of physical memory.\**
628 \** The 4.1BSD system used for testing was really a 4.1a
630 with networking facilities and code to support
631 remote file access. The
632 4.2BSD system also included the remote file access code.
634 systems would be larger than similarly configured ``vanilla''
635 4.1BSD or 4.2BSD system, we consider out conclusions to still be valid.
637 This resulted in more page faults and, hence, more system time.
638 To establish a common ground on which to compare the paging
639 routines of each system, we check instead the average page fault
640 service times for those test runs that had a statistically significant
641 number of random page faults. These figures, shown in Table 8, show
642 no significant difference between the two systems in
643 the area of page fault servicing. We currently have
644 no explanation for the results of the sequential
650 l || c s || c s || c s || c s
651 l || c s || c s || c s || c s
652 l || c | c || c | c || c | c || c | c
653 l || n | n || n | n || n | n || n | n.
654 Test Real User System Page Faults
656 \^ 4.1 4.2 4.1 4.2 4.1 4.2 4.1 4.2
658 seqpage 959 1126 16.7 12.8 197.0 213.0 17132 17113
659 seqpage-v 579 812 3.8 5.3 216.0 237.7 8394 8351
660 randpage 571 569 6.7 7.6 64.0 77.2 8085 9776
661 randpage-v 572 562 6.1 7.3 62.2 77.5 8126 9852
662 gausspage.1 25 24 23.6 23.8 0.8 0.8 8 8
663 gausspage.10 26 26 22.7 23.0 3.2 3.6 2 2
664 gausspage.30 34 33 25.0 24.8 8.6 8.9 2 2
665 gausspage.40 42 81 23.9 25.0 11.5 13.6 3 260
666 gausspage.50 113 175 24.2 26.2 19.6 26.3 784 1851
667 gausspage.60 191 234 27.6 26.7 27.4 36.0 2067 3177
668 gausspage.80 312 329 28.0 27.9 41.5 52.0 3933 5105
669 gausspage.inf 619 621 82.9 85.6 68.3 81.5 8046 9650
672 Table 7. Paging benchmark results (all times in seconds).
683 Test Page Faults PFST
687 randpage 8085 9776 791 789
688 randpage-v 8126 9852 765 786
689 gausspage.inf 8046 9650 848 844
692 Table 8. Page fault service times (all times in microseconds).
projects / dragonfly.git / blob