HBO剛演完一部愛情片

壞心情的時候，我可以選擇不去學校，因為沒有老闆會扣我錢
但是上班的人卻無法和我一樣，他們必需強掩自己鬱悶
不僅僅是因為薪水問題，更因為和所謂的"同事"根本少有真情感的交流
我已慢慢走出天真的世界
就算我還不算正式蹋入，但我身旁早有很多"導師"不停的灌輸給我訊息

對冤獄的電影有感覺
無法想像如果也發生在自己身上
我可以撐多久?
我會不會自爆自棄?
20年…真的很長…  我目前30也才渡過一個20年…

在苦痛時，如果發現有人比你更苦痛，常常會覺得自己的還不算什麼

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

temp

Understanding Performance Interference of I/O Workload  in Virtualized  Cloud Environments

Easy and Efficient Disk I/O Workload Characterization in VMware

http://blogs.oracle.com/henk/entry/swat_a_disk_and_tape   swat workload analyzer

Libtrace: A Trace Capture and Processing Library

指標...

1.  int *a[10]
2.  int (*a)[10]

自己理出的規則如下:  
array前面是array的名子

int *a[10] ，a是array的名子，然後這個array放的是 int *
int (*a)[10]，(*a)是array的名子，然後array裡面放的是 int