推 shibin: 好奇一問,mlock()有成功嗎 01/14 13:02
→ Lipraxde: 你想要什麼硬性的 page fault...? 01/14 13:23
推 sarafciel: 15us的話應該是minor page fault,可以試試看perf 01/14 13:24
→ Lipraxde: 程式在向 OS 要 memory 時,實際上 OS 是先預留位置, 01/14 13:35
→ Lipraxde: 直到實際去存取要到的位置時 (觸發了 page fault 後) 01/14 13:35
→ Lipraxde: 才會真的去更新 page table,屬於 recoverable 的 01/14 13:35
→ Lipraxde: 想避免的話也許用 mmap + MAP_POPULATE? 01/14 13:44
推 jaid: madvise? 01/14 16:06
→ laughingman: 抱歉可能描述不清楚讓大家誤會了,mlock()有成功, 01/14 18:19
→ laughingman: 所以我想說在使用mlock()時跑/usr/bin/time -v應該 01/14 18:20
→ laughingman: 看不到minor page fault,可是仍然顯示有一樣多的 01/14 18:22
→ laughingman: (甚至更多)的minor page fault,這樣無法解釋mlock() 01/14 18:24
→ laughingman: 真的有解決原有的page fault問題。 01/14 18:25
推 dces4212: 語言runtime在載入.so時也會有page fault 或許可以試試 01/15 03:29
→ dces4212: 在你感興趣的程式碼前後用getrusage來觀察page fault次 01/15 03:29
→ dces4212: 數比較精準 01/15 03:29
推 LiloHuang: 總是會有 page fault 只是發生時間早晚問題 01/15 14:30
→ LiloHuang: 從mmap 拿到的 address 再跑 madvise + MADV_HUGEPAGE 01/15 14:35
→ LiloHuang: 使用 huge page (e.g. 2M) 應該就能減少次數了 01/15 14:36
→ LiloHuang: std::vector default allocator 也不一定是 mmap 來的 01/15 14:38
→ LiloHuang: 建議自己用 mmap 寫個 custom allocator 01/15 14:39
→ laughingman: 謝謝各位大神的建議,我再研究看看,有結果再跟大家 01/16 06:43
→ laughingman: 分享,感恩。 01/16 06:43