Use rtld's TLS interface to allocate tcb.
[dragonfly.git] / share / doc / smm / 05.fastfs / 4.t
1 .\" Copyright (c) 1986, 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 .\"
31 .\"
32 .\"     @(#)4.t 8.1 (Berkeley) 6/8/93
33 .\"
34 .ds RH Performance
35 .NH 
36 Performance
37 .PP
38 Ultimately, the proof of the effectiveness of the
39 algorithms described in the previous section
40 is the long term performance of the new file system.
41 .PP
42 Our empirical studies have shown that the inode layout policy has
43 been effective.
44 When running the ``list directory'' command on a large directory
45 that itself contains many directories (to force the system
46 to access inodes in multiple cylinder groups),
47 the number of disk accesses for inodes is cut by a factor of two.
48 The improvements are even more dramatic for large directories
49 containing only files,
50 disk accesses for inodes being cut by a factor of eight.
51 This is most encouraging for programs such as spooling daemons that
52 access many small files,
53 since these programs tend to flood the
54 disk request queue on the old file system.
55 .PP
56 Table 2 summarizes the measured throughput of the new file system.
57 Several comments need to be made about the conditions under which these
58 tests were run.
59 The test programs measure the rate at which user programs can transfer
60 data to or from a file without performing any processing on it.
61 These programs must read and write enough data to
62 insure that buffering in the
63 operating system does not affect the results.
64 They are also run at least three times in succession;
65 the first to get the system into a known state
66 and the second two to insure that the 
67 experiment has stabilized and is repeatable.
68 The tests used and their results are
69 discussed in detail in [Kridle83]\(dg.
70 .FS
71 \(dg A UNIX command that is similar to the reading test that we used is
72 ``cp file /dev/null'', where ``file'' is eight megabytes long.
73 .FE
74 The systems were running multi-user but were otherwise quiescent.
75 There was no contention for either the CPU or the disk arm.
76 The only difference between the UNIBUS and MASSBUS tests
77 was the controller.
78 All tests used an AMPEX Capricorn 330 megabyte Winchester disk.
79 As Table 2 shows, all file system test runs were on a VAX 11/750.
80 All file systems had been in production use for at least
81 a month before being measured.
82 The same number of system calls were performed in all tests;
83 the basic system call overhead was a negligible portion of
84 the total running time of the tests.
85 .KF
86 .DS B
87 .TS
88 box;
89 c c|c s s
90 c c|c c c.
91 Type of Processor and   Read
92 File System     Bus Measured    Speed   Bandwidth       % CPU
93 _
94 old 1024        750/UNIBUS      29 Kbytes/sec   29/983 3%       11%
95 new 4096/1024   750/UNIBUS      221 Kbytes/sec  221/983 22%     43%
96 new 8192/1024   750/UNIBUS      233 Kbytes/sec  233/983 24%     29%
97 new 4096/1024   750/MASSBUS     466 Kbytes/sec  466/983 47%     73%
98 new 8192/1024   750/MASSBUS     466 Kbytes/sec  466/983 47%     54%
99 .TE
100 .ce 1
101 Table 2a \- Reading rates of the old and new UNIX file systems.
102 .TS
103 box;
104 c c|c s s
105 c c|c c c.
106 Type of Processor and   Write
107 File System     Bus Measured    Speed   Bandwidth       % CPU
108 _
109 old 1024        750/UNIBUS      48 Kbytes/sec   48/983 5%       29%
110 new 4096/1024   750/UNIBUS      142 Kbytes/sec  142/983 14%     43%
111 new 8192/1024   750/UNIBUS      215 Kbytes/sec  215/983 22%     46%
112 new 4096/1024   750/MASSBUS     323 Kbytes/sec  323/983 33%     94%
113 new 8192/1024   750/MASSBUS     466 Kbytes/sec  466/983 47%     95%
114 .TE
115 .ce 1
116 Table 2b \- Writing rates of the old and new UNIX file systems.
117 .DE
118 .KE
119 .PP
120 Unlike the old file system,
121 the transfer rates for the new file system do not
122 appear to change over time.
123 The throughput rate is tied much more strongly to the
124 amount of free space that is maintained.
125 The measurements in Table 2 were based on a file system
126 with a 10% free space reserve.
127 Synthetic work loads suggest that throughput deteriorates
128 to about half the rates given in Table 2 when the file
129 systems are full.
130 .PP
131 The percentage of bandwidth given in Table 2 is a measure
132 of the effective utilization of the disk by the file system.
133 An upper bound on the transfer rate from the disk is calculated 
134 by multiplying the number of bytes on a track by the number
135 of revolutions of the disk per second.
136 The bandwidth is calculated by comparing the data rates
137 the file system is able to achieve as a percentage of this rate.
138 Using this metric, the old file system is only
139 able to use about 3\-5% of the disk bandwidth,
140 while the new file system uses up to 47%
141 of the bandwidth.
142 .PP
143 Both reads and writes are faster in the new system than in the old system.
144 The biggest factor in this speedup is because of the larger
145 block size used by the new file system.
146 The overhead of allocating blocks in the new system is greater
147 than the overhead of allocating blocks in the old system,
148 however fewer blocks need to be allocated in the new system
149 because they are bigger.
150 The net effect is that the cost per byte allocated is about
151 the same for both systems.
152 .PP
153 In the new file system, the reading rate is always at least
154 as fast as the writing rate.
155 This is to be expected since the kernel must do more work when
156 allocating blocks than when simply reading them.
157 Note that the write rates are about the same 
158 as the read rates in the 8192 byte block file system;
159 the write rates are slower than the read rates in the 4096 byte block
160 file system.
161 The slower write rates occur because
162 the kernel has to do twice as many disk allocations per second,
163 making the processor unable to keep up with the disk transfer rate.
164 .PP
165 In contrast the old file system is about 50%
166 faster at writing files than reading them.
167 This is because the write system call is asynchronous and
168 the kernel can generate disk transfer
169 requests much faster than they can be serviced,
170 hence disk transfers queue up in the disk buffer cache.
171 Because the disk buffer cache is sorted by minimum seek distance,
172 the average seek between the scheduled disk writes is much
173 less than it would be if the data blocks were written out
174 in the random disk order in which they are generated.
175 However when the file is read,
176 the read system call is processed synchronously so
177 the disk blocks must be retrieved from the disk in the
178 non-optimal seek order in which they are requested.
179 This forces the disk scheduler to do long
180 seeks resulting in a lower throughput rate.
181 .PP
182 In the new system the blocks of a file are more optimally
183 ordered on the disk.
184 Even though reads are still synchronous, 
185 the requests are presented to the disk in a much better order.
186 Even though the writes are still asynchronous,
187 they are already presented to the disk in minimum seek
188 order so there is no gain to be had by reordering them.
189 Hence the disk seek latencies that limited the old file system
190 have little effect in the new file system.
191 The cost of allocation is the factor in the new system that 
192 causes writes to be slower than reads.
193 .PP
194 The performance of the new file system is currently
195 limited by memory to memory copy operations
196 required to move data from disk buffers in the
197 system's address space to data buffers in the user's
198 address space.  These copy operations account for
199 about 40% of the time spent performing an input/output operation.
200 If the buffers in both address spaces were properly aligned, 
201 this transfer could be performed without copying by
202 using the VAX virtual memory management hardware.
203 This would be especially desirable when transferring
204 large amounts of data.
205 We did not implement this because it would change the
206 user interface to the file system in two major ways:
207 user programs would be required to allocate buffers on page boundaries, 
208 and data would disappear from buffers after being written.
209 .PP
210 Greater disk throughput could be achieved by rewriting the disk drivers
211 to chain together kernel buffers.
212 This would allow contiguous disk blocks to be read
213 in a single disk transaction.
214 Many disks used with UNIX systems contain either
215 32 or 48 512 byte sectors per track.
216 Each track holds exactly two or three 8192 byte file system blocks,
217 or four or six 4096 byte file system blocks.
218 The inability to use contiguous disk blocks
219 effectively limits the performance
220 on these disks to less than 50% of the available bandwidth.
221 If the next block for a file cannot be laid out contiguously,
222 then the minimum spacing to the next allocatable
223 block on any platter is between a sixth and a half a revolution.
224 The implication of this is that the best possible layout without
225 contiguous blocks uses only half of the bandwidth of any given track.
226 If each track contains an odd number of sectors, 
227 then it is possible to resolve the rotational delay to any number of sectors
228 by finding a block that begins at the desired 
229 rotational position on another track.
230 The reason that block chaining has not been implemented is because it
231 would require rewriting all the disk drivers in the system,
232 and the current throughput rates are already limited by the
233 speed of the available processors.
234 .PP
235 Currently only one block is allocated to a file at a time.
236 A technique used by the DEMOS file system
237 when it finds that a file is growing rapidly,
238 is to preallocate several blocks at once,
239 releasing them when the file is closed if they remain unused.
240 By batching up allocations, the system can reduce the
241 overhead of allocating at each write,
242 and it can cut down on the number of disk writes needed to
243 keep the block pointers on the disk
244 synchronized with the block allocation [Powell79].
245 This technique was not included because block allocation 
246 currently accounts for less than 10% of the time spent in
247 a write system call and, once again, the
248 current throughput rates are already limited by the speed
249 of the available processors.
250 .ds RH Functional enhancements
251 .sp 2
252 .ne 1i