不,是的,也許吧.這取決于.

調用mmap通常只意味著對應用程序而言,映射文件的內容將映射到其地址空間,就像文件已加載到那里一樣.或者,好像該文件確實存在于內存中,就好像它們是同一個(包括更改被寫回磁盤,假設您具有寫訪問權限).

不多也不少.它沒有加載某些東西的概念,應用程序也不知道這意味著什么.

應用程序并不真正了解內存等任何內容,盡管虛擬內存系統使其看起來像這樣.應用程序可以“看到”(和訪問)的內存可能或可能不對應于實際的物理內存,原則上這可以隨時更改,無需事先警告,也沒有明顯的原因(對您的應用程序來說很明顯).

除了可能由于頁面錯誤而經歷小的延遲之外,應用程序(原則上)完全不知道發生任何此類事情并且幾乎沒有或沒有對它的控制1.

通常,應用程序將根據需要從映射文件(包括主可執行文件！)加載頁面,這是遇到故障的結果.但是,操作系統通常會嘗試推測性地預取數據以優化性能.

在實踐中,調用mmap將立即開始(異步)從映射的開始預取頁面,直到某個實現指定的大小.原則上,對于小文件,這意味著答案是“是”,對于較大的文件,這將是“否”.

但是,mmap不會阻止等待readahead的完成,這意味著在mmap返回后你不能保證任何文件立即存在于RAM中(不管你在任何時候都有這種保證！).就此而言,答案是“也許”.

在Linux下,我上次看,默認的預取大小是31個塊(~127k) – 但這可能已經改變,加上它是一個可調參數.當觸摸預取區域附近或末尾的頁面時,異步預取更多頁面.

如果你暗示MADV_RANDOM是瘋狂的,預取“不太可能發生”,在Linux下這完全禁用了預取.

另一方面,給出MADV_SEQUENTIAL提示將從映射的開始開始異步地預取“更積極地”(并且可以更快地丟棄被訪問的頁面).在Linux下,“更積極”意味著正常數量的兩倍.

給出MADV_WILLNEED提示建議(但不保證)盡快加載給定范圍內的所有頁面(因為您說要訪問它們).操作系統可能會忽略這一點,但在Linux下,它被視為一個訂單而不是一個提示,直到進程的最大RSS限制和一個實現指定的限制(如果我沒記錯的話,是物理內存量的1/2) ).

請注意,MADV_DONTNEED可以說是在Linux下錯誤地實現的.提示不是按POSIX指定的方式解釋的,即您可以暫時將頁面分頁,而是指您要丟棄它們.這對于只讀映射的頁面沒有什么大的區別(除了一個小的延遲,你說它可以),但它肯定對其他一切都很重要.

特別是,使用MADV_DONTNEED認為Linux會在操作系統將它們懶惰地寫入磁盤后釋放不需要的頁面,這不是事情的運作方式！您必須明確同步或準備驚喜.

在調用mmap之前調用了文件描述符的readahead(或者之前已經讀過/寫過文件),文件的內容實際上確實會立即存在于RAM中.

但是,這只是一個實現細節(統一虛擬內存系統),并受系統內存壓力的影響.

調用mlock將 – 假設成功2 – 立即將請求的頁面加載到RAM中.它會阻塞,直到所有頁面都存在,并且您可以保證頁面將保留在RAM中,直到您將其解鎖.

1存在查詢(mincore)特定范圍內的任何或所有頁面是否實際存在的功能,以及提示操作系統關于您希望在沒有任何硬保證(madvise)的情況下發生的事情的功能,最后,強制有限的頁面子集出現在內存(mlock)中以實現特權進程的功能.

2它可能不會,因為缺乏特權和超額配額或物理RAM的數量.

總結

以上是生活随笔為你收集整理的linux文件 内存映射 锁,linux – mmap：将映射文件立即加载到内存中吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。