Performance Analysis and Optimization of the Hurricane File System ...

More documents

Recommendations

Info

CHAPTER 7. MACROBENCHMARK 73 disk # file# modulo 16 meta−file block# modulo 16 Logical Organization of Hash Table for Block Cache 0 1 11 0 1 15 0 1 15 0 1 15 0 1 15 0 1 15 0 1 15 Physical Implentation of Hash Table for Block Cache 0 1 15 0 1 15 block # 0 1 15 0 1 15 0 1 15 block # 0 1 15 0 1 1516 31 239 255 global index 2816 3071 file #0 file #1 file #15 file #0 file #1 file #15 disk #0 7 Constructing Hash Index Value for Block Cache global hash index value = 6 5 4 3 disk # 2 1 0 11 10 9 8 17 4 3 2 1 0 31 file# (embedded in file token) 7 start here 6 5 4 3 2 1 0 4 3 2 1 meta−file block # Figure 7.3: Modified block cache hash function. disk #11 12 processors and 12 disks. Ideally, the size of the hash table should scale accordingly to the size of the multiprocessor, as implied by Peacock et al. [56, p. 86]. There are effectively 3 chances for hash collision avoidance, based on disk number, file token number, and file block number. Consider 2 threads that are executing in parallel on separate processors. If the threads access different disks, then hash collisions will not occur. However, if they access the same disk 5 , the chance of collisions is mitigated by the availability of 16 hash list groups. If the threads access different hash list groups, then hash collisions will not occur. The threads may access the same hash list group if either (1) they are accessing the same file, or (2) they are accessing different files on the same disk but the corresponding file numbers cause them to hash to the same hash list group. Even if the threads hash into the same hash list group, there are 16 hash lists within each group to reduce the probability of hash collisions. If the two 5 This cannot occur in our experiments. 0
CHAPTER 7. MACROBENCHMARK 74 avg # cycles per processor 6e+10 4e+10 2e+10 0e+00 2 4 6 8 10 12 # processors Unoptimized Optimized Optimized 2 Figure 7.4: Web server – further optimized. avg # cycles per processor 6e+10 4e+10 2e+10 0e+00 2 4 6 8 10 12 # processors Unoptimized Optimized Optimized 2 smaller Optimized 2 Figure 7.6: Web server – further optimized, smaller. avg # cycles per processor 2e+09 1.5e+9 1e+09 5e+08 0e+00 2 4 6 8 10 12 # processors Optimized 2 Figure 7.5: Web server – further optimized, magnified. avg # cycles per processor 5e+09 4e+09 3e+09 2e+09 1e+09 0e+00 2 4 6 8 10 12 # processors Optimized 2 smaller Optimized 2 Figure 7.7: Web server – further optimized, smaller, magnified. threads are accessing the same file, hash collisions may still not occur if they access sufficiently different locations of the file, since access to the group of 16 hash lists is roughly based on file block number. The results from these additional optimizations are shown in Figure 7.4 with the curve labeled “Op- timized 2”. Scalability was greatly improved, however, ideal scalability was not achieved. The resulting curve, magnified in Figure 7.5, indicates a minor scalability degradation. Average thread execution time on 12 processors was 67% greater than on a uniprocessor. To briefly examine sensitivity to the number of hash lists in a grouping, the ORS cache hash list group size was reduced from 64 to 16, and the block cache hash list group size was reduced from 256 to 64. The results are shown Figure 7.6 and Figure 7.7 6 with the curve labeled “Optimized 2 smaller”. As expected, the curve was shifted higher, but minor scalability problems unexpectedly reappeared since the slope of the curve has increased slightly. The modified hash function guaranteed exclusive hash list access under our particular workload so the scalability problems were not caused by hash list sharing. We did not investigate these scalability problems further since the smaller 6 64 MB of RAM was used on the dual processor configuration instead of 128 MB due to OS stability problems.
Page 1 and 2:
Performance Analysis and Optimizati
Page 3 and 4:
Acknowledgements This thesis has be
Page 5 and 6:
4.6 Measurements Taken and Graph In
Page 7 and 8:
List of Tables 3.1 File system inte
Page 9 and 10:
6.1 Create. . . . . . . . . . . . .
Page 11 and 12:
CHAPTER 1. INTRODUCTION AND MOTIVAT
Page 13 and 14:
CHAPTER 1. INTRODUCTION AND MOTIVAT
Page 15 and 16:
CHAPTER 2. BACKGROUND AND RELATED W
Page 17 and 18:
Page 19 and 20:
Page 21 and 22:
Page 23 and 24:
Chapter 3 HFS Architecture This cha
Page 25 and 26:
CHAPTER 3. HFS ARCHITECTURE 16 3.1.
Page 27 and 28:
CHAPTER 3. HFS ARCHITECTURE 18 ORS
Page 29 and 30:
CHAPTER 3. HFS ARCHITECTURE 20 dirt
Page 31 and 32: CHAPTER 3. HFS ARCHITECTURE 22 dire
Page 33 and 34: CHAPTER 3. HFS ARCHITECTURE 24 1. 2
Page 35 and 36: CHAPTER 3. HFS ARCHITECTURE 26 curr
Page 37 and 38: CHAPTER 4. EXPERIMENTAL SETUP 28 1
Page 39 and 40: CHAPTER 4. EXPERIMENTAL SETUP 30 de
Page 41 and 42: CHAPTER 4. EXPERIMENTAL SETUP 32 av
Page 43 and 44: Chapter 5 Microbenchmarks - Read Op
Page 45 and 46: CHAPTER 5. MICROBENCHMARKS - READ O
Page 61 and 62: Chapter 6 Microbenchmarks - Other F
Page 63 and 64: CHAPTER 6. MICROBENCHMARKS - OTHER
Page 75 and 76: Chapter 7 Macrobenchmark 7.1 Purpos
Page 77 and 78: CHAPTER 7. MACROBENCHMARK 68 server
Page 79 and 80: CHAPTER 7. MACROBENCHMARK 70 avg #
Page 81: CHAPTER 7. MACROBENCHMARK 72 Logica
Page 85 and 86: CHAPTER 7. MACROBENCHMARK 76 avg #
Page 87 and 88: CHAPTER 7. MACROBENCHMARK 78 7.5 Ot
Page 89 and 90: CHAPTER 7. MACROBENCHMARK 80 to deq
Page 91 and 92: CHAPTER 8. CONCLUSIONS 82 8.1 Gener
Page 93 and 94: CHAPTER 8. CONCLUSIONS 84 read-only
Page 95 and 96: Bibliography [1] Gene M. Amdahl. Va
Page 97 and 98: BIBLIOGRAPHY 88 [33] David Kotz, So
Page 99: BIBLIOGRAPHY 90 [71] Keith A. Smith
show all

Performance Analysis and Optimization of the Hurricane File System ...

Create successful ePaper yourself

Delete template?

Save as template?