lrfu (least recently/frequently used) block replacement policy

Seoul National University

Archi & Network LAB

LRFU (Least Recently/Frequently Used)Block Replacement Policy

Sang Lyul Min

Dept. of Computer Engineering



Archi & Network LAB

Why file cache?

Processor - Disk Speed Gap

1950’s 1990’s

• Processor - IBM 701

• 17,000 ins/sec

• Disk - IBM 305 RAMAC

• Density - 0.002 Mbits/sq. in

• Average seek time - 500 ms

• Processor - IBM PowerPC 603e

• 350,000,000 ins/sec

• Disk - IBM Deskstar 5

• Density - 1,319 Mbits/sq. in

• Average seek time - 10 ms

x 600,000

x 50

x 20,000


Archi & Network LAB

File Cache

main memory disk controller

file cache or buffer cache disk cache

processor disks


Archi & Network LAB

Operating System 101

• LRU Replacement • LFU Replacement

LRU Block

MRU Block

LFU Block

MFU Block

New reference

New reference

O(1) complexity O(n) complexity

heap

O(log n) complexity


Archi & Network LAB

Operating System 101

• LRU– Advantage

• High Adaptability

– Disadvantage• Short sighted

• LFU– Advantage

• Long sighted

– Disadvantage• Cache pollution


Archi & Network LAB

Motivation

• Cache size = 20 blocks


Archi & Network LAB



Archi & Network LAB

Observation

• Both recency and frequency affect the likelih

ood of future references

• The relative impact of each is largely determi

ned by cache size


Archi & Network LAB

Goal

A replacement algorithm that allows a flexible trade-off between recency and frequency


Archi & Network LAB

Results

LRFU (Least Recently/Frequently Used)

Replacement Algorithm that

(1) subsumes both the LRU and LFU

algorithms

(2) subsumes their implementations

(3) yields better performance than them


Archi & Network LAB

CRF (Combined Recency and Frequency) Value

Current time tc

time

t3t2t1

Ctc(b) = F(1) + F(2) + F(3) || || || tc - t1 tc - t2 tc - t3

1 23


Archi & Network LAB

CRF (Combined Recency and Frequency) Valu

e

• Estimate of how likely a block will be

referenced in the future

• Every reference to a block contributes to the

CRF value of the block

• A reference’s contribution is determined by

weighing function F(x)


Archi & Network LAB

Hints and Constraints on F(x)

• should be monotonically decreasing

• should subsume LRU and LFU

• should allow efficient implementation


Archi & Network LAB

Conditions for LRU and LFU

• LRU Condition– If F(x) satisfies the following condition, then the LRF

U algorithm becomes the LRU algorithm

• LFU Condition– If F(x) = c, then the LRFU algorithm becomes the L

FU algorithm

1ij

F(j)F(i) i

block a: xblock b: x x x x x x x x

i

i+1i+2

i+3

currenttime


Archi & Network LAB

Weighing function F(x)

F(x) = ()x

Meaning: a reference’s contribution to the target

block’s CRF value is halved after every 1/


Archi & Network LAB

Properties of F(x) = ()x

• Property 1

– When = 0, (i.e., F(x) = 1), then it becomes LFU

– When = 1, (i.e., F(x) = ()x ), then it becomes LRU

– When 0 < < 1, it is between LFU and LRU

F(x) = ()x (LRU extreme)

Spectrum(LRU/LFU)

1

0

F(x) = 1 (LFU extreme)F(x)

Xcurrent time - reference time


Archi & Network LAB

Results



(1) subsumes both the LRU and LFU algorithms




Archi & Network LAB

Difficulties of Naive Implementation

• Enormous space overheads

– Information about the time of every reference to

each block

• Enormous time overheads

– Computation of the CRF value of every block at

each time


Archi & Network LAB

Update of CRF value over timet1

time

t2

= (t2 - t1)

1

2 3

C t2(b) = F (1+) + F (2+) + F (3+)

= ()(1+ ) + () (2+ ) + () (3+ )

= (()1 + ()2 + ()3 ) ()

= C t1(b) x F ()


Archi & Network LAB


• Property 2– With F(x) = ()x, Ctk(b) can be computed from Ctk-1(b) as

follows

Ctk(b) = Ctk-1(b) F () + F (0) || tk - tk-1

– Implications: Only two variables are required for each block for maintaining the CRF value

• One for the time of the last reference

• The other for the CRF value at that time


Archi & Network LAB

Difficulties of Naive Implementation

• Enormous space overheads

– Information about the time of every reference to

each block

• Enormous time overheads

– Computation of the CRF value of every block at

each time


Archi & Network LAB


• Property 3– If Ct(a) > Ct(b) and neither a or b is referenced afte

r t, then Ct'(a) > Ct'(b) for all t' > t• Why?

Ct'(a) = Ct(a) F() > Ct(b) F() = Ct'(b) (since F() > 0 )

• Implications– Reordering of blocks is needed only upon a block r

eference– Heap data structure can be used to maintain the o

rdering of blocks with O(log n) time complexity


Archi & Network LAB

Optimized Implementation

Blocks that can compete with a

currently referenced block


Archi & Network LAB

linked list

heap

1. replaced

2. demoted3. new block4. heap restored

linked list

heap

1. demoted

2. promoted

referencedblock

3. heaprestored

linked list

heap

referenced block1. heap

restored

Optimized Implementation

Reference to a new block

Reference to a block in the linked list

Reference to a block in the heap


Archi & Network LAB

QuestionWhat is the maximum number of blocks that

can potentially compete with a currently referenced block?


Archi & Network LAB

• • •

block a: x

block b: x x x x x

time

• • • + F(d threshold +2) + F(d threshold +1) + F(d threshold ) < F(0)

dthreshold

dthreshold +1

dthreshold +2

currenttime


• Property 4 :

log (1- ())

dthreshold =

log (1- ())

When 0

When 1

=

= 1log (1- ())


Archi & Network LAB

Optimized implementation (Cont’d)

linked list linked list

heap(single element)

LRU extreme

LFU extreme

heap

linked list (null)

heap

O(log n) O(1)


Archi & Network LAB


Archi & Network LAB

Results







Archi & Network LAB

Correlated References

correlated references



LRFU with correlated references

• Masking function Gc(x)

• C'tk(b), CRF value when correlated references are consid

ered, can be derived from C'tk-1(b)

C'tk(b) = F(tk - tk) + F(tk - ti )*Gc(ti+1 - ti )

= F( tk - tk-1) * [F(0) * Gc( tk - tk-1) + C'tk-1(b) - F(0)] + F(0)

period correlated :c c,x:1

cx:0(x)Gc

1k

1i


Archi & Network LAB

Trace-driven simulation

• Sprite client trace

– Collection of block references from a Sprite client

– contains 203,808 references to 4,822 unique blocks

• DB2 trace

– Collection of block references from a DB2 installation

– Contains 500,000 references to 75,514 unique blocks


Archi & Network LAB

Effects of on the performance

(b) DB2

Hit Rate

X

X

X

X

Hit Rate

(a) Sprite client

X

X

X

X


Archi & Network LAB

Combined effects of and correlated period

Hit Rate

CorrelatedPeriod

(a) Sprite client

Hit Rate

CorrelatedPeriod

(b) DB2


Archi & Network LAB

Previous works• FBR (Frequency-Based Replacement) algorithm

– Introduces correlated reference concept

• LRU-K algorithm– Replaces blocks based on time of the K’th-to-last non-correlated references

– Discriminates well the frequently and infrequently used blocks

– Problems• Ignores the K-1 references • linear space complexity to keep the last K reference times

• 2Q and sLRU algorithms– Use two queues or two segments

– Move only the hot blocks to the main part of the disk cache

– Work very well for “used-only-once” blocks


Archi & Network LAB

Comparison of the LRFU policy with other policies

Hit Rate

Cache Size (# of blocks)

(a) Sprite client

Hit Rate

Cache Size (# of blocks)

(b) DB2


Archi & Network LAB

Implementation of the LRFU algorithm

• Buffer cache of the FreeBSD 3.0 operating sy

stem

• Benchmark: SPEC SDET benchmark

– Simulates a multi-programming environment

– consists of concurrent shell scripts each with abou

t 150 UNIX commands

– gives results in scripts / hour


Archi & Network LAB

SDET benchmark results

CacheSize

LRU LRFU

50 69.6 71.2

100 70.0 73.6

200 71.2 74.9

300 72.4 75.7

Hit rate SDET Throughput

(scripts/ hour)Hit Rate


Archi & Network LAB


Archi & Network LAB

Conclusions







Archi & Network LAB

Future Research

• Dynamic version of the LRFU algorithm

• LRFU algorithm for heterogeneous workloads

– File requests vs. VM requests

– Disk block requests vs. Parity block requests (RAI

D)

– Requests to different files (index files, data files)


Archi & Network LAB

People

• REAL PEOPLE (Graduate students)

– Lee, Donghee

– Choi, Jongmoo

– Kim, Jong-Hun

• Guides (Professors)

– Noh, Sam H.

– Min, Sang Lyul

– Cho, Yookun

– Kim, Chong Sang

http://archi.snu.ac.kr/symin/

Adaptive LRFU policy

• Adjust periodically depending on the evolution of workload

• Use the LRU policy as the reference model to quantify how good (or bad) the locality of the workload has been

• Algorithm of the Adaptive LRFU policy

– if ( > )

value for period i+1 is updated in the same direction

– else the direction is reversed

1)(iHIT

1)(iHIT(i)Hit

LRFU

LRFULRFU

1)(iHIT

1)(iHIT(i)Hit

LRU

LRULRU


Archi & Network LAB

Results of the Adaptive LRFU

CacheSize

LRU LRFU AdaptiveLRFU

1200 0.5588 0.6049 0.5872

1500 0.6494 0.7326 0.7093

2000 0.7939 0.8634 0.8461

2500 0.9198 0.9440 0.9291

3000 0.9657 0.9726 0.9707

Client Workstation 54

CacheSize

LRU LRFUAdaptive

LRFU

1000 0.6544 0.6899 0.6772

3000 0.7295 0.7527 0.7463

5000 0.7625 0.7802 0.7652

7000 0.7809 0.7962 0.7815

10000 0.8009 0.8107 0.8023

DB2


Archi & Network LAB

lrfu (least recently/frequently used) block replacement policy

Documents