APP: MINIMIZING INTERFERENCE USING AGGRESSIVEPIPELINED PREFETCHING IN MULTI-LEVEL BUFFER CACHES

Transcription

1 APP: MINIMIZING INTERFERENCE USING AGGRESSIVEPIPELINED PREFETCHING IN MULTI-LEVEL BUFFER CACHES Christina M. Patrick Pennsylvania State University Nicholas Voshell Pennsylvania State University Mahmut Kandemir Pennsylvania State University du th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing

2 OUTLINE 1. Introduction 2. AGGRESSIVE PIPELINED PREFETCHING (APP) 3. Software support 4. Prefetching aggressiveness 5. Linux prefeth 6. Experiment evaluation 7. Conclusion

3 INTRODUCTION 1. Multi-level buffer cache hierarchies have become common in the computing domain. 2. Customers as well as clouds run a number of servers on different machines in order to increase the efficiency of the operation. 3. Each machines have its own buffer cache. 4. Like storage servers, applications request data from database server to them and pass it back by reverse route. 5. When central severs access simultaneously different I/O request and I/O stream, client will compete for disk attention and spending most of time seeking due to the continuous switching between I/O stream. Also the overall I/O throughput goes down.

4 INTRODUCTION Storage model: Hierarchical buffer caches are very common in the cloud and internet

5 INTRODUCTION 1. In this hierarchy, the application is run on the client nodes and the data is stored on disks. 2. The A node is connected to the storage servers through one or more intermediate servers, but storage servers are the only nodes directly connected to the disks 3. These nodes may be heterogeneous and the size of the cache on each node may be different. 4. All buffer caches are fully associative and are configured to use the same block(page) size.

6 INTRODUCTION 1. compute nodes :nodes that execute applications 2. I/O nodes: nodes connected to the disks 3. Compute nodes forward request to I/O node and choose the nearest node, and it is assumed that all I/O node are served by the same shared file system. 4. I/O node do not store prefected data because all request forward to them, data usually replaced. 5. Owing to be page aligned when we exchange data between node, we divide a file into blocks of size equal to buffer cache block size

7 AGGRESSIVE PIPELINED PREFETCHING 1. We partition cache on each node into two component, one to accommodate local request and the other for pipelined prefetch data.(we reserve one forth for tunable space.) 2. This scheme utilizes remote storage caches as a staging area. If node N 0 requests B 0 bytes of data from a file starting at offset O 0, it will forward the read request I 0, O 0, B 0 to I/O node N D by the path N 1 N 2 N D APP module will modify the read request I 0, O 0, B 0 + PPW 0 where PPW 0 is the pipeline prefetch window size on node N 0. Size varies on all intermediate node in flow.

8 AGGRESSIVE PIPELINED PREFETCHING 1. When the request arrives at the I/O server N D, the final read request is I 0, O 0, B 0 + PPW 0 + PPW 1 + PPW PPW D 1 2. The PPW size is tunable and it depends on the number of useful pipeline prefetches issued in the past for related flows. 3. (access the same file or inode) 4. We hide the latency seen at the end nodes by pipeling the request.when half the PPW i has been consumed by application requests on node N 0, we issue a new request I 0, O 0 + B 0 + PPW 0, PPW 0 ensure that data will be fetched on N 0 before the entire window of PPW 0 bytes has been consumed.

9 AGGRESSIVE PIPELINED PREFETCHING

10 SOFTWARE SUPPORT 1. Packet format 1. source address(s) 2. destination address (D) 3. message id field (ID) 4. Pipeline prefetch (PP) bit 5. the file inode 6. the offset to which we perform I/O and the number of bytes in the I/O operation 2. ID=0x0 stands for a read request from a compute node 3. ID=0x1 indicating a response containing data from an I/O node. The PP bit indicate if the pipelined prefetching has been turned on(1) or Turn off(0).

11 SOFTWARE SUPPORT Data Structures struct _state{ uint inode, bool phase; uint PPW; uint src:4, uint dst:4; uint pipe_accesses, uint pipe_hits; uint pend_offset; uint pend_size; }; phase is used to identify the phase of the pipeline prefetch aggressiveness algorithm and to decide the pipeline prefetch window size PPW at a node Ni. pipe_accesses maintains the total number of pipeline prefetches that have been issued so far i.e, past and present. pipe_hits gives the total number of useful pipeline prefetches for all the related flows

12 SOFTWARE SUPPORT 1. When the request is cached partially, we check to see the contiguous range of the data at the head of the request present in the cache. 2. Data cache locally may form hole in the request. 3. Using a slide window to handle assembly of message received partially 4. Messages are assembled and asynchronous transfer in the background

13 PREFETCHING AGGRESSIVENESS T p (average disk position time) = T ctrl + T seek + T spin 2 T s (disk service time) = T p + T xfer (disk transfer time) disks with rotational speed of 10K RPM exhibitthe following average values: 1. T seek 5ms 2. T spin 3ms 3. Tracksize 550KB In order to maintain high disk throughput,t xfer must dominatet s, i.e., T xfer T p, hence we set ppw of a workload: T xfer = 9T p = 9(T seek + T spin 2 ) The values are chosen such that Tseek and Tspin account for less that 10% of total disk service time

14 PREFETCHING AGGRESSIVENESS 1. maintain a high throughput, we set the upper bound on the PPW to 19.5 tracks 550 KB/track 10 MB. 2. #Track = 9(T seek + T spin ) 2 T spin 9( ) 3 = PPW max = 19.5tracks 550 KB track 10MB

15 PREFETCHING AGGRESSIVENESS 1. The pipeline prefetch hit rate is defined as the ratio of the useful pipeline prefetches to the total number of pipeline prefetches. 2. When we encounter a new flow, it turn the prefetch by setting PP=1 and the PPW=1 and enters the warmup phase of APP. 3. Warmup phase : 4. PPW i = 4PPW i, if PPW quadruples every related flow until the PPW 16 pages. We choose this value since it is equal to half the maximum Linux prefetch window.

16 PREFETCHING AGGRESSIVENESS 1. After the warmup phase, it begins the steady state of the algorithm and track useful prefetches on every node 1. UP i is the total number of prefetch hits 2. TP i is the total number of prefetch 2. PPW i = min 2PPW i, PPW max if ( UP i TP i 0.75) 1 and PP = 0 if ( UP i 0.10) TP i 1 PPW 2 i if ( UP i 0.25) TP i PPW i, oterwise 3. In summary, the more successful the APP scheme, the larger the PPW setting

17 LINUX PREFETCH 1. there are two windows: 1. (i) current window (pages requested by the file system) 2. (ii) ahead window (pages to be prefetched). 2. The size of the ahead window (AW) changes adaptively and is related to the size of the current window (CW) 3. If the first access to a file is the first data block in the file, then it is classified as a sequential access. Otherwise, it is classified as a random access. If the read ahead miss flag of an access stream is set, then we have AW=CW-2 (min=4), and if not, we have AW=2 CW or 4 CW (max=32).

18 LINUX PREFETCH 1. Maximum number of pages prefetched under Linux is 32 pages, 2. The I/O node then forwards this data to the requesting node N 0 with the multi-level hierarchy, and data is sent over to N 0 whrer it s cache locally. 3. When applications issue a new request, it checked local cache. If it is cache miss, it will cause full penalty of disk read, network store,forward latency and node processing.

19 EXPERIMENT EVALUATION 1. Our experiments run on a 16-node Linux cluster. Each machine in the testbed is a dual-core AMD Athlon node with 512 MB main memory connected by 1GBps Ethernet. We used 10K RPM Seagate Cheetah disks for our experiments. We implemented our APP module in Linux We used an extremely I/O-intensive application used in studies of the scalability Radix-k algorithm for parallel image composition

20 EXPERIMENT EVALUATION

21 EXPERIMENT EVALUATION

22 EXPERIMENT EVALUATION

23 EXPERIMENT EVALUATION

24 CONCLUSION APP is a novel scheme designed to manage the application I/O streams and the buffer caches in a multi-level cache hierarchy in order to increase I/O throughput by reducing I/O interference APP makes use of aggressive prefetching to increase the throughput of the interfering I/O streams. This performance improvement by APP is measured beyond the prefetching performance provided by the Linux kernel