28.07.2013 Views

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

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

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

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

CHAPTER 6. MICROBENCHMARKS – OTHER FUNDAMENTAL OPERATIONS 55<br />

avg # cycles per processor<br />

1e+10<br />

8e+09<br />

6e+09<br />

4e+09<br />

2e+09<br />

0e+00<br />

2 4 6 8 10 12<br />

# processors<br />

Unoptimized 20 pool<br />

Figure 6.7: Lookup – unoptimized.<br />

6.2.4 + 200 Entries Pool<br />

avg # cycles per processor<br />

1e+10<br />

8e+09<br />

6e+09<br />

4e+09<br />

2e+09<br />

0e+00<br />

2 4 6 8 10 12<br />

# processors<br />

Unoptimized 20 pool<br />

Unoptimized 200 pool<br />

Figure 6.8: Lookup – 200 initial<br />

pool.<br />

avg # cycles per processor<br />

4e+09<br />

3e+09<br />

2e+09<br />

1e+09<br />

0e+00<br />

2 4 6 8 10 12<br />

# processors<br />

Unoptimized 200 pool<br />

Figure 6.9: Lookup – 200 initial<br />

pool, magnified.<br />

Influenced by <strong>the</strong> results that will be shown in Section 6.3.1 for <strong>the</strong> file name lookup workload, <strong>the</strong> initial<br />

pool <strong>of</strong> block cache entries was increased from 20 to 200 to resolve a potential anomaly in <strong>the</strong> block cache<br />

entry allocation algorithm. This experiment is o<strong>the</strong>rwise identical in configuration to Section 6.2.3. The<br />

results, as shown in Figure 6.6, indicate that <strong>the</strong> small initial pool <strong>of</strong> block cache entries was not <strong>the</strong> cause<br />

<strong>of</strong> <strong>the</strong> scalability problem.<br />

6.2.5 Summary<br />

The optimizations implemented from file read experiments were applicable to <strong>the</strong> file creation operation.<br />

<strong>File</strong> creation scalability was improved drastically. On 12 processors, approximately an order <strong>of</strong> magnitude<br />

<strong>of</strong> improvement was achieved. However, ideal scalability was not achieved since threads performed 3 times<br />

slower on a 12 processor configuration than on a uniprocessor configuration. Even worse, performance trends<br />

indicate that thread execution time will continue to grow linearly past 12 processors. We were unable to<br />

improve scalability any fur<strong>the</strong>r for this particular workload<br />

6.3 <strong>File</strong> Name Lookup<br />

In this set <strong>of</strong> experiments, we examine <strong>the</strong> scalability <strong>of</strong> <strong>the</strong> file name lookup operation. As described in<br />

Section 3.6.2 on page 25, <strong>the</strong> name lookup operation returns a file token identifier for a given path name.<br />

The file token allows for easy identification <strong>of</strong> <strong>the</strong> target file by <strong>the</strong> file system <strong>and</strong> is used by clients to<br />

identify specific files.<br />

In <strong>the</strong> first experiment, <strong>the</strong> unoptimized HFS configuration <strong>of</strong> Section 5.2 was used. Each thread per-<br />

formed a file look up <strong>of</strong> <strong>the</strong> same, one file: DiskXXX:/directory1/directory2/directory3/directory4/

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!