Amount Of Cache Research Articles

Fast media caching for geo-distributed data centers

Recent years have witnessed a phenomenal increase in video traffic. Virtual content delivery networks (vCDNs) coordinate video content delivery through the use of computing and storage resources from the cloud and distributes content to edge nodes near consumers to reduce network traffic and improve service experience. An important objective of vCDNs is operation cost minimization. Since cloud data centers are geo-distributed, content transfer costs vary significantly with different data centers, i.e., the cost is high for retrieval from distant data centers and lower for nearby retrievals. Many popular caching algorithms in use today, such as Lru, do not consider cost when making caching decisions, and as a result, suffer from high data transfer costs and increased network congestion. On the other hand, cost-aware caching algorithms such as LandLord [1] are computationally inefficient, with time complexity scaling linearly to the amount of content in the vCDN. Such algorithms are unable to keep pace with the exponential growth in video content over time. In this paper, we propose Fmc(fast media caching), a cost-aware and highly efficient caching algorithm for vCDN delivery over geo-distributed data centers. The load cost of each content item is determined by both the item’s size and distance from the data center it is loaded from. We first prove that Fmc is kk−h+1 competitive under the resource augmentation paradigm, where Fmc and the optimal offline adversary have k and h amount of cache, resp., and k ≥ h. Also, we show our algorithm is straightforward and efficient, requiring only O(log m) time per cache access, where m is the number of data centers and is a small constant in practice. We conduct experimental studies on Fmc using both synthetic and YouTube traces. Our results show that Fmc has on average 50% and up to 66.7% lower cost than Lru. Besides, we show Fmc is much faster than LandLord, and the speedup scales linearly with cache size.

Using Memory in the Right Way to Accelerate Big Data Processing

Big data processing is becoming a standout part of data center computation. However, latest research has indicated that big data workloads cannot make full use of modern memory systems. We find that the dramatic inefficiency of the big data processing is from the enormous amount of cache misses and stalls of the depended memory accesses. In this paper, we introduce two optimizations to tackle these problems. The first one is the slice-and-merge strategy, which reduces the cache miss rate of the sort procedure. The second optimization is direct-memory-access, which reforms the data structure used in key/value storage. These optimizations are evaluated with both micro-benchmarks and the real-world benchmark HiBench. The results of our micro-benchmarks clearly demonstrate the effectiveness of our optimizations in terms of hardware event counts; and the additional results of HiBench show the 1.21X average speedup on the application-level. Both results illustrate that careful hardware/software co-design will improve the memory efficiency of big data processing. Our work has already been integrated into Intel distribution for Apache Hadoop.

The sharing architecture

Businesses and Academics are increasingly turning to Infrastructure as a Service (IaaS) Clouds such as Amazon's Elastic Compute Cloud (EC2) to fulfill their computing needs. Unfortunately, current IaaS systems provide a severely restricted pallet of rentable computing options which do not optimally fit the workloads that they are executing. We address this challenge by proposing and evaluating a manycore architecture, called the Sharing Architecture, specifically optimized for IaaS systems by being reconfigurable on a sub-core basis. The Sharing Architecture enables better matching of workload to micro-architecture resources by replacing static cores with Virtual Cores which can be dynamically reconfigured to have different numbers of ALUs and amount of Cache. This reconfigurability enables many of the same benefits of heterogeneous multicores, but in a homogeneous fabric, and enables the reuse and resale of resources on a per ALU or per KB of cache basis. The Sharing Architecture leverages Distributed ILP techniques, but is designed in a way to be independent of recompilation. In addition, we introduce an economic model which is enabled by the Sharing Architecture and show how different users who have varying needs can be better served by such a flexible architecture. We evaluate the Sharing Architecture across a benchmark suite of Apache, SPECint, and parts of PARSEC, and find that it can achieve up to a 5x more economically efficient market when compared to static architecture multicores. We implemented the Sharing Architecture in Verilog and present area overhead results.

The sharing architecture

Businesses and Academics are increasingly turning to Infrastructure as a Service (IaaS) Clouds such as Amazon's Elastic Compute Cloud (EC2) to fulfill their computing needs. Unfortunately, current IaaS systems provide a severely restricted pallet of rentable computing options which do not optimally fit the workloads that they are executing. We address this challenge by proposing and evaluating a manycore architecture, called the Sharing Architecture, specifically optimized for IaaS systems by being reconfigurable on a sub-core basis. The Sharing Architecture enables better matching of workload to micro-architecture resources by replacing static cores with Virtual Cores which can be dynamically reconfigured to have different numbers of ALUs and amount of Cache. This reconfigurability enables many of the same benefits of heterogeneous multicores, but in a homogeneous fabric, and enables the reuse and resale of resources on a per ALU or per KB of cache basis. The Sharing Architecture leverages Distributed ILP techniques, but is designed in a way to be independent of recompilation. In addition, we introduce an economic model which is enabled by the Sharing Architecture and show how different users who have varying needs can be better served by such a flexible architecture. We evaluate the Sharing Architecture across a benchmark suite of Apache, SPECint, and parts of PARSEC, and find that it can achieve up to a 5x more economically efficient market when compared to static architecture multicores. We implemented the Sharing Architecture in Verilog and present area overhead results.

IBM System z10 design for RAS

The IBM System z10™ server reliability, availability, and serviceability (RAS) design continues to reduce the sources of server outages through innovative RAS architecture and techniques. The z10™ server introduced functional improvements that challenged the RAS design. Increases were made in the performance of each processor, the total number of processors, the total size of the memory, the amount of cache, the bandwidth of the I/O, the thermal density, and the exposure to soft errors. These changes demanded stronger RAS functions to prevent unscheduled outages. Significant improvements were made to the IBM e-business on demand® functions (concurrent, customer-requested upgrades) that enable customers to better manage capacity without having to take planned outages. The hypervisor simplified configuration changes, such as adding cryptography or channel subsystems to logical partitions, by eliminating the need for preplanning. Single-core checkstopping and single transparent CPU (central processing unit) sparing were added. The RAS functions reduced the number of scheduled outages. Product improvements were complemented by improvements in RAS modeling. This paper describes these RAS improvements and how they provide value to the customer.

Caching policy design and cache allocation in active reliable multicast

Active reliable multicast (ARM) is a novel loss recovery scheme for large-scale reliable multicast. It uses active routers to perform NACK (negative-acknowledgement) consolidation and scoped retransmission. For optimizing the loss recovery performance of ARM under limited cache resources, the work in this paper aims at designing efficient and robust cache allocation schemes and caching policies. When a packet arrives at an active router, a caching policy determines if this packet should be cached and if cached, for how long. Three caching policies, timer-based, simple FIFO and probabilistic FIFO, are investigated in this paper. For a given amount of cache, the cache allocation problem is to find the best way to allocate the cache to each active router such that the overall network loss recovery performance can be optimized. Three cache allocation schemes, equal sharing, least requirement first and proportional allocation, are proposed. Among all the combinations of cache allocations and caching policies, we found that the proportional cache allocation with probabilistic FIFO caching policy gives the best overall performance.

Performance evaluation and cache analysis of an ILP protocol implementation

Integrated layer processing (ILP) is an implementation concept that "permits the implementor the option of performing all the (data) manipulation steps in one or two integrated processing loops". To estimate the achievable benefits of ILP, a file transfer application with an encryption function on top of a user-level TCP has been implemented and the performance of the application in terms of throughput and packet processing times has been measured. The results show that it is possible to obtain performance benefits by integrating marshalling, encryption, and TCP checksum calculation. The experiments yielded in a throughput gain of only 10-20% in contrast to the 50% gain achieved for simple loop experiments. Simulations of memory access and cache hit rate show that the main benefit of ILP is reduced memory access rather than an improved cache hit rate. ILP reduced the number of memory accesses up to 30% in the experiment, but the relative amount of cache misses could not be reduced compared to a carefully designed non-ILP implementation. The results also show that data manipulation characteristics may significantly influence the cache behavior and the achievable performance gain of ILP. Considering these results, ILP can only be recommended in cases where the the ILP loop consists of several, but very simple data manipulations without complex calculations over the data.