在系統記憶體上…特別是tmpfs、、shm、和hugepages...之間的區別
我最近對各種基於 Linux 核心記憶體的文件系統感到好奇。
*
Note:*就我而言，與更好地理解標題中提出的問題相比，以下問題或多或少應該被認為是可選的。我在下面問他們，因為我相信回答他們可以更好地幫助我理解差異，但由於我的理解是有限的，因此其他人可能更了解。我準備接受任何可以豐富我對標題中提到的三個文件系統之間差異的理解的答案。最終，我想我想安裝一個可用的文件系統，*
hugepages,儘管一些簡單的研究（以及更輕鬆的修補）讓我相信 arewritable hugepage mount*不是一種選擇。我弄錯了嗎？這裡的機制是什麼？還有關於*
hugepages:*uname -a 3.13.3-1-MANJARO \ #1 SMP PREEMPT \ x86_64 GNU/Linux tail -n8 /proc/meminfo HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 8223772 kB DirectMap2M: 16924672 kB DirectMap1G: 2097152 kB（這裡是/proc/meminfo和/proc/cpuinfo的全文版本）
上面發生了什麼？我是否已經分配記憶體頁和記憶體頁*
hugepages?之間是否有區別？DirectMap**hugepages?*更新在@Gilles 的一點推動下，我在上面又添加了 4 行，似乎一定有區別，儘管在昨天*
DirectMap拉動之前我從未聽說過tail……也許DMI*還是什麼？只是多了一點…
努力失敗*
hugepages，並假設任何圖像文件的硬碟備份，安裝循環的風險tmpfs?是什麼我的文件系統是swapped最壞的情況？我了解tmpfs*掛載的文件系統記憶體 - 我掛載的循環文件是否會被記憶體不足？我可以採取哪些緩解措施來避免這種情況？最後——到底是什麼*
shm,？hugepages它與或有什麼不同或包括tmpfs?*
tmpfs 和 shm 之間沒有區別。tmpfs 是 shm 的新名稱。shm 代表共享記憶體。
請參閱：Linux tmpfs。
今天甚至使用 tmpfs 的主要原因是我在我的 gentoo 盒子上的 /etc/fstab 中的這條評論。順便說一句，Chromium 不會在缺少該行的情況下建構：
# glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for # POSIX shared memory (shm_open, shm_unlink). shm /dev/shm tmpfs nodev,nosuid,noexec 0 0報價：
tmpfs 有以下用途：
- 總有一個核心內部掛載，您根本看不到
。這用於共享匿名映射和 SYSV 共享
記憶體。
此掛載不依賴於 CONFIG_TMPFS。如果未設置 CONFIG_TMPFS，則不會建構 tmpfs 的使用者可見部分。但內部
機制始終存在。
- glibc 2.2 及更高版本期望 tmpfs 安裝在 /dev/shm 以用於
POSIX 共享記憶體（shm_open、shm_unlink）。將以下行添加
到 /etc/fstab 應該解決這個問題：
tmpfs /dev/shm tmpfs 預設值 0 0
如有必要，請記住創建要掛載 tmpfs 的目錄。
SYSV 共享記憶體不需要此掛載。內部
安裝用於此。（在 2.3 核心版本中，
需要掛載 tmpfs（shm fs）的前身才能使用 SYSV
共享記憶體）
- 有些人（包括我）發現掛載它非常方便，
例如掛載在 /tmp 和 /var/tmp 上並且有一個大的交換分區。現在
循環掛載 tmpfs 文件確實可以工作，所以大多數發行版提供的 mkinitrd
應該通過 tmpfs /tmp 成功。
4）可能還有很多我不知道的:-)
tmpfs 具有三個用於調整大小的掛載選項：
size： 為此 tmpfs 實例分配的字節數限制。預設值為沒有交換的物理 RAM 的一半。如果您的 tmpfs 實例過大，則機器將死鎖，因為 OOM 處理程序將無法釋放該記憶體。
**nr_blocks：**與大小相同，但在 PAGE_CACHE_SIZE 的塊中。
**nr_inodes：**此實例的最大 inode 數。預設值為物理 RAM 頁數的一半，或（在具有 highmem 的機器上）lowmem RAM 頁數，以較低者為準。
來自透明大頁核心文件：
與hugetlbfs 的保留方法相比，透明大頁面支持通過允許所有未使用的記憶體用作記憶體或其他可移動（甚至不可移動的實體）來最大化空閒記憶體的有用性。它不需要保留來防止從使用者空間注意到大頁面分配失敗。它允許在大頁面上使用分頁和所有其他高級 VM 功能。應用程序無需修改即可利用它。
然而，應用程序可以進一步優化以利用此功能，例如，它們之前已經過優化以避免每個 malloc(4k) 的大量 mmap 系統呼叫。到目前為止，優化使用者空間並不是強制性的，而且 khugepaged 已經可以處理長壽命的頁面分配，即使對於處理大量記憶體的不知道大頁面的應用程序也是如此。
做一些計算後的新評論：
HugePage 大小：2MB
使用的 HugePages：無/關閉，由全 0 證明，但根據上面的 2Mb 啟用。
DirectMap4k：8.03Gb
DirectMap2M：16.5Gb
DirectMap1G：2Gb
使用上面關於 THS 優化的段落，看起來您的 8Gb 記憶體正被使用 4k、16.5Gb 的 malloc 執行的應用程序使用，而使用 2M 的 malloc 的應用程序已請求。使用 2M 的 malloc 的應用程序通過將 2M 部分解除安裝到核心來模仿 HugePage 支持。這是首選方法，因為一旦核心釋放了 malloc，記憶體就會釋放給系統，而使用 hugepage 掛載 tmpfs 不會導致完全清理，直到系統重新啟動。最後，最簡單的一個，你有 2 個程序打開/執行，請求 1Gb 的 malloc
對於那些不知道 malloc 是 C 中的標準結構的讀者，它代表記憶體分配。這些計算證明了 OP 在 DirectMapping 和 THS 之間的相關性可能是正確的。另請注意，僅安裝 HUGEPAGE fs 只會增加 2MB 的增量，而讓系統使用 THS 管理記憶體主要發生在 4k 塊中，這意味著就記憶體管理而言，每個 malloc 呼叫都會節省系統 2044k(2048 - 4 ) 供其他程序使用。