We have presented CLIC, a technique for managing a storage server cache based on hints from storage client applications. CLIC provides a general, adaptive mechanism for incorpo- rating application-provided hints into cache management. We used trace-driven simulation to evaluate CLIC, and found that it was effective at learning to exploit hints. In our tests, CLIC learned to perform as well as or better than TQ, an ad hoc hint based technique. In many scenarios, CLIC also performed substantially better than hint-oblivious techniques such as LRU and ARC. Our results also show that CLIC, unlike TQ and other ad hoc techniques, can accommodate hints from multiple client applications.
are valuable. We considered a simple technique for limiting this overhead, which involves identifying frequently-occurring hints and tracking statistics only for those hints. In many cases, we found that it was possible to significantly reduce the number of hints that CLIC had to track with only minor degradation in performance. However, although tracking only frequent hints is a good way to reduce overhead, the overhead is not eliminated and the space required for good performance may increase with the number of hint types that CLIC encounters. In Chapter 5, we apply a feature selection technique to generalize hint sets by grouping related hint sets together into a common class. We expect that this approach, together with the frequency-based approach, can enable CLIC to accommodate a large number of hint types.
Chapter 4
Dynamic Priority CLIC
As discussed in Chapter 3, the lower-tier cache is hard to manage because the temporal locality in the request streams has been filtered by the upper-tier cache. Zhou et al. [76] use reuse distance (the same as re-reference distance defined in Chapter 3) histograms to observe the temporal locality of several traces of requests to the lower-tier cache. They point out that the reuse distance histograms of these traces exhibit two common patterns. First, all histograms are hill-shaped, which is not true of reuse histograms for the upper- tier cache. For example, Figure 4.1 shows the histograms obtained by grouping reuse distances by powers of two. Compared to the upper-tier cache (Figure 4.1(a)), in which 74 percent of references have a reuse distance less than or equal to 16, of the references to the lower-tier cache have 99 percent reuse distance is greater than 512 (Figure4.1(b)). Thus, recency-based replacement algorithms, which work well for the upper-tier cache, do not work well for the lower-tier cache. Second, the beginning, peak and end of the “hill” region, while different, all depend on the size of the upper-tier cache and workload characteristics. Because most references occur in the hill portion, Zhou et al. [76] argue that a good algorithm for the lower-tier cache should retain blocks in the cache long enough to reach the hill. By examining block access frequency, they find that blocks accessed more frequently contribute more access in the hill region. Thus, they propose a cache replacement policy called MQ to combine the temporal locality and access frequency to make replacement decisions.
While it is clear that re-reference distance histograms for all requests to the lower-tier cache are hill-shaped, the re-reference distance histograms for requests with the same hint set have not been examined. Our hint-based replacement algorithm – CLIC (in Chapter3) is based on the hint benefit/cost model. For each hint set passed by the storage clients, CLIC calculates the hint caching priority using the overall read hit rate and the mean re-reference distance of each hint set. All pages with the same hint set have the same caching priority, and are managed in one LRU list. However, if the re-reference distance histograms of each hint set are hill-shaped, LRU, which is designed to take advantage of temporal locality, may not be a good way for CLIC to manage pages with the same hint
beginning
peak
end
Figure 4.1: Temporal Locality of Upper-tier and Lower-tier Cache Accesses Using Reuse Distance Histograms. (a) Auspex Client Trace and (b) Auspex Server trace[76].
set.
Our hypothesis is that the re-reference distance histograms of requests with the same hint set exhibit an access pattern similar to that of all requests. In CLIC, the page priority is assigned as the priority (Pr(H)) of the hint set H with which that page was last requested. The page priority will not change until the page is requested again. Intuitively, as the read hit rates do not distribute evenly and vary with the re-reference distance, the page caching priority should also depend on how long the page has stayed in the cache. Thus, we propose to collect re-reference histograms for each hint set so that read hit rates can be calculated based on re-reference distance. Then we propose to perform a dynamic benefit/cost analysis for each hint set. Since CLIC manages pages with fixed caching priorities, we address the following questions in this chapter:
• Are the re-reference distance histograms of requests with the same hint set also hill- shaped?
• Can the performance of CLIC be improved by considering how long a page has been in the cache?
We also extend CLIC to provide a new algorithm – dynamic priority CLIC (DP-CLIC), which is based on a dynamic benefit/cost model. Unlike the page caching priority in CLIC, the page caching priority of DP-CLIC not only depends on the hint sets attached to the most recent request for the page, but also on how long the page has been in the cache. DP- CLIC further improves the lower-tier cache performance by making replacement decision using dynamic caching priority.
38 114 190 266 342 418 494 570 646 722 Re-reference distance (X5000) 0 20000 40000 60000 80000 100000 N um be r of r ea ds
hint set A hint set B hint set C
DB2_C300_400 (a) 50 150 250 350 450 550 650 750 850 950 Re-reference distance (X5000) 0 200 400 600 800 1000 1200 Number of reads
hint set A hint set B hint set C
DB2_C540_400
(b)
Figure 4.2: Read Reference Distance Histograms of DB2 TPC-C Workload Traces
4.1
Re-reference Histogram of Hint Sets
In order to understand the access pattern in terms of hint sets, we collected re-reference histograms for each hint set from the DB2 traces, using the approach described in Sec-
tion3.2.2. Figure 4.2 shows read reference histograms of several sample hint sets from the
DB2 traces. We see that the read reference histograms are all hill-shaped, which correspond to that of all requests to lower-tier caches. Different hint sets’ re-reference histograms have different peaks and hill shapes. After pages are placed in the cache, they are most likely to be read during the hill region. In each histogram, after the end of the hill region, there is a long “tail” which has lower read probability with longer distances. Intuitively, the caching priority should drop after the hill region because the benefit is lower and the cost is higher compared to that in the hill region. However, the benefit/cost model of CLIC cannot detect the hill region. Instead, it keeps the page caching priority unchanged until the page is requested again. In the worst case, a page which is requested with a high priority hint set may stay in the cache forever without any benefit.