爲什麼malloc依賴於從某個閾值開始的mmap？

我正在讀關於malloc的一點點，發現在的malloc的手冊頁以下：爲什麼malloc依賴於從某個閾值開始的mmap？

通常的malloc（）分配從堆內存，並調整大小所需的堆，使用SBRK （2）。當分配大於MMAP_THRESHOLD字節的存儲塊的塊時，glibc malloc（）實現使用mmap（2）將存儲器分配爲私有匿名映射。 MMAP_THRESHOLD默認爲128 kB，但使用mallopt（3）可調整爲。使用mmap（2）執行的分配是，不受RLIMIT_DATA資源限制的影響（請參閱getrlimit（2））。

所以基本上從閾值MMAP_THRESHOLD malloc開始使用mmap開始。

是否有任何理由切換到mmap大塊？
這是否會觸及流程執行性能？
mmap系統調用是否強制上下文切換？

來源

2015-10-14 redobot

（1）是; （2）理論上是的，但實際上這在大多數情況下提高了性能，這是（1）的原因; （3）每個系統調用都會。 –

@ n.m。並非所有的系統調用都需要上下文切換。看看下面的線程http://stackoverflow.com/questions/9238326/system-call-and-context-switch – redobot

顯然這是術語上的差異。你可能想知道mmap是否阻塞。通話本身可能不會被阻止，但它並不重要。無論如何，你的進程將會出現頁面錯誤並被迫進入上下文切換。 –

（1）通過匿名mmap獲取的頁面可以通過munmap發佈，這是glibc正在做的事情。因此，對於小的分配，free將內存返回到進程的堆（但將它們保留在進程的內存中）;對於較大的分配，free將內存作爲一個整體返回給系統。

（2）通過匿名mmap獲取的頁面在您第一次訪問它們之前並未實際分配。此時，內核必須將它們清零以避免進程之間泄漏信息。所以，是的，mmap獲得的頁面第一次訪問比通過你的進程堆回收的頁面要慢。您是否會注意到差異取決於您的應用程序。

不使用mmap的成本是釋放的內存仍然受限於進程，並且不可用於系統上的其他進程。所以這最終是一種折衷。（3）它不會「強制」上下文切換，並且我相信這不會導致上下文切換。 mmap實際上沒有分配頁面;它只是操縱你的過程的頁面地圖。這通常應該是一個非阻塞操作。（雖然我承認我對此並不是100％確定的。）

來源

2015-10-14 17:00:25 Nemo

感謝您的回答。我仍在研究第3點，以查看mmap是否強制切換上下文。 – redobot

爲什麼malloc依賴於從某個閾值開始的mmap？

回答

相關問題