Linux檔案系統預讀二

前一篇文章仔細描述了最簡單的一種預讀情況：單程序檔案順序讀，且讀大小不超過32頁面，這裡我們來看另外一種情境：單程序檔案順序讀，讀大小為256kb，看看預讀邏輯如何處理這種情況，照例首先給出事例**：

事例**中我們一共進行了三次讀，順序讀，且讀的大小不定，有超過最大預讀量的，也有低於最大預讀量的。

毫無疑問，由於第一次讀肯定未在快取命中，前一篇部落格告訴我們需要進行一次同步預讀，需要初始化預讀視窗

initial_readahead:
ra->start = offset;
ra->size = get_init_ra_size(req_size, max);
// ra->size 一定是》= req_size的，這個由get_init_ra_size保證
// 如果req_size >= max,那麼ra->async_size = ra_size
ra->async_size = ra->size > req_size ? ra->size - req_size : ra->size;
readit:
/*	 * will this read hit the readahead marker made by itself?
* if so, trigger the readahead marker hit now, and merge
* the resulted next readahead window into the current one.
*/if (offset == ra->start && ra->size == ra->async_size) 
}

在初始化預讀視窗中判斷得出：ra->size=32 pages，即使應用程式要讀的數量是40 pages，這樣ra->async_size = ra->size=32 pages，在readit邏輯判斷成立，因此會重設ra->async_size的值，根據計算應該是32 pages，而總的ra->size=初始值+ra->async_size=64 pages。形成的預讀視窗為(0, 64, 32)，如下圖：

由於應用程式本次訪問的實際頁面是page0 ~page40（由於同步預讀會全部在快取命中），因此在訪問過程中會碰到page32，此時觸發一次非同步預讀，並向前推進預讀視窗：

/* 如果:
** 1. 順序讀(本次讀偏移為上次讀偏移 (ra->start) + 讀大小(ra->size,包含預讀量) - 
**    上次預讀大小(ra->async_size))
** 2. offset == (ra->start + ra->size)???
*/if ((offset == (ra->start + ra->size - ra->async_size) ||
offset == (ra->start + ra->size)))

更新後的當前預讀視窗為(64, 32, 32)，如下：

因此，經過第一次讀以後，該檔案在記憶體中page cache狀態如下圖所示：

由於第二次讀只需讀出page40 ~ page55，直接在page cache中命中，也不會觸發一次非同步預讀，預讀視窗也不會更新，因此，該過程非常簡單。本次讀完以後，檔案在記憶體page cache的狀態如下：

應用程式第三次讀的範圍為page56 ~ page87，由上圖可知，這些均可以在page cache中命中，但是由於訪問了page64，因此會觸發一次非同步預讀，且當前的預讀視窗為(64, 32, 32)，根據上面的演算法更新預讀視窗為(96, 32, 32)，因此，本次預讀完成以後，檔案在page cache中的快取狀態如下：

我們可以將本情境與上篇部落格中描述的情境對比，其實可以發現兩者思想完全一致，只是由於應用程式讀的粒度不同導致了預讀的粒度更大，僅此而已。

Linux檔案系統預讀二

linux 檔案系統 Linux 檔案系統結構介紹

檔案系統虛擬檔案系統（二）

Linux檔案系統

Linux檔案系統預讀 二

linux 檔案系統 Linux 檔案系統結構介紹

檔案系統 虛擬檔案系統（二）

Linux檔案系統

相關推薦

Linux檔案系統預讀二

檔案系統虛擬檔案系統（二）