idea: content-aware buffer manager

以下稱  content LRU  為 CLRU，也就是  list 上只串著 FingerPrint (FP)  ，search 時只比對 content。和傳統的LRU比較(i.e., ALRU ，也就是 list 上只串著address和content，search 時只比對 address
有DEDUP功能的系統，buffer中會有   CLRU 和 ALRU

----------------------------
idea 1
    hot-content first LRU :
    rationale : CLRU中的某 content 很 hot ，那ALRU中可以不必放此content了，因為有高機會會被de  掉。

idea 2
    RAM放FP較好，還是放content較好?    → 分析這一刀該切在那
    maybe，也可以adaptive調整。

EXlru

http://home.ustc.edu.cn/~shil0704/conf/PDF_EMSOFT_11_1.pdf motivation : lack of page-level access information in the block based WBC ---------------------- 點出  以block-level為 LRU排序的單位 的壞處。     (a) Slow retirement of large cold blocks          只因少數page更新，而讓整個blk(連同cold pages)都搬到MRU去     (b) Early eviction of small hot blocks          ex. 假設 block A有31個pages ，每個page都只被update 1 次                      block B有3  個pages ，每個page都被update 10 次                 誰該留在buffer中久一點??   應該要是 B -----------solution----- add page-level access information (VPN, Data, Hit_count, Request_number)   自己推出一套計算權重的方法來決定 eviction order