Improving Application Performance through Swap Compression

1. Improving Application Performance through Swap Compression R. Cervera, T. Cortes, Y. Becerra and S. Lucas

2. Motivation • Problem • Large applications • Highly-loaded systems • Laptops • Laptops usually have less resources than desktops • Homework • Home machines are usually smaller than office machines • Solution • Swapping mechanism • But … IT IS VERY SLOW !!!

3. Objectives • Increase swapping performance • Without adding more memory • Increase swapping space • Without adding more disk • Performance is more important than space • Modify the kernel as little as possible • Mechanism feasible in user-level libraries

4. Page Fault Swap Out Swap In Traditional Swapping Path Process B Process C Process A Process D Operating System Swap Device

5. Proposal • Cache for swapped pages • If the system uses memory for the cacheThen the applications lose this memory • Problem: • Less fast memory • More slow memory • Compression of swapped pages • More than one compressed page per buffer

6. D C D Compressed Swapping v1.0 Operating System Cache Swap Device

7. Hit Ratio and Its Kinds • There are two kind of cache hits • Hits due write • Page recently swapped out • Hits due read • Page brought to the cache with another request • Many more hits due write than hits due read • Different swap-in and swap-out order • No spatial locality • Reads produce interferences in the cache

8. Optimizations • Different read and write paths • Reads do not place information in the cache • Reads use the cache (hits due write) • Reads do not modify the cache • Writes place information in the cache • Writes modify the cache • Batched writes • Write many cache buffers to disk at the same time • Write them contiguously • A page is never split among two buffers • Reads perform, at most, one disk access

9. D C D Compressed Swapping v2.0 Operating System Cache Swap Device

10. Evaluated Environment • Environment • Pentium II - 350Mhz • 64 Mbytes of memory • Ultra-SCSI disk, 128 Mbytes swap partition • Bencmarks

11. Performance Evaluation 6,5 • Parameters • Cache size = 1Mbyte • Cleaning threshold =50% • Better performance • Speedups better than 1.2 • FFT • Speedup = 0.96 • Bad compression ratio • Working set • Simulator x5 • Good compression ratio • All pages fit in the cache

12. Cache-size Influence • No perfect cache size • Large caches are bad • Use too much application memory • Recomended size • Around 1Mbyte

13. Batched-write Influence • Small values are bad • Small writes • Latency is not hidden • Large values • Mono-process bench • Good • Multi process bench • Reads confilct with cleans • Recommended value • Around 10%

14. New-swap Capacity • Some improvement achieved • Allows larger applications • Depends on • Compression ratio • Fragmentation

15. Related Work • Compressed cache (Douglis93) • No difference between reads and writes • Limited batched writes • Performance gains only for applications with high compression ratio • Single process benchmarks • MagnaRAM • Memory compression for Windows • Not very good results

16. Conclusions • Simple mechanism to: • Increase performance of large applications • Increase swap space • Easy to implement • Modified • 6 routines and 2 files • Added • 9 routines and 1 include file (.h) • Easy to port from one version to another • 15 minutes • Can be used in out-of-core applications