處理器x86/x86_64中是否使用物理或虛擬尋址在L1，L2和L3中緩存？

在處理器x86/x86_64中使用哪種尋址方式在L1，L2和L3（LLC）中進行緩存 - 物理或虛擬（使用PT/PTE和TLB），並且PAT(page attribute table)會對其產生影響嗎？處理器x86/x86_64中是否使用物理或虛擬尋址在L1，L2和L3中緩存？

在這種情況下驅動程序（內核空間）和應用程序（用戶空間）之間是否有區別？

來源

2013-09-26 Alex

您無法尋址緩存。你只能處理內存。緩存由CPU私下處理。 –

@Kerrek SB是的我知道，但CPU緩存是否使用TLB和虛擬尋址的所有開銷？ – Alex

你的問題的答案是 - 這取決於。這完全是一個CPU設計決策，它在性能和複雜性之間權衡。以最近的英特爾酷睿處理器爲例 - 它們被物理標記並虛擬索引（至少根據http://www.realworldtech.com/sandy-bridge/7/）。這意味着高速緩存只能在純物理地址空間中完成查找，以確定該行是否存在。然而，由於L1是32k，8路聯合，這意味着它使用64組，所以你只需要地址位6到11以便找到正確的組。碰巧，虛擬地址和物理地址在這個範圍內是相同的，因此您可以通過讀取緩存集合來並行查找DTLB - 一種已知的技巧（請參閱 - http://en.wikipedia.org/wiki/CPU_cache以獲得更好的解釋）。

理論上，人們可以構建一個虛擬索引+虛擬標記的緩存，這將消除通過地址轉換（TLB查找以及在TLB未命中情況下的頁面散播）的要求。但是，這會造成很多問題，尤其是內存別名問題 - 兩個虛擬地址映射到同一物理地址的情況。

說core1有虛擬地址緩存在這樣一個完全虛擬的緩存中（它映射到phys addr C，但我們還沒有完成這個檢查）。 core2寫入映射到同一個phys addr C的虛擬地址B - 這意味着我們需要一些機制（通常是由Jim Goodman創造的「snoop」），並使core1中的那條線無效，管理數據合併和一致性管理如果需要的話。但是，core1無法回答該snoop，因爲它不知道虛擬地址B，也不會將物理地址C存儲在虛擬高速緩存中。所以你可以看到我們有一個問題，雖然這主要與嚴格的x86系統相關，但是其他架構可能更加鬆懈，並且允許對這種緩存進行更簡單的管理。

關於其他問題 - 我沒有想到與PAT有真正的聯繫，緩存已經設計好，不能針對不同的內存類型進行更改。另一個問題的答案是相同的 - 硬件主要是在用戶/內核模式（除了爲安全檢查提供的機制之外，主要是各種環）之間的區別之下。

來源

2013-09-27 20:58:35 Leeor

非常感謝！在你看來，是否從x86機制的知識中獲益？以及作爲開發人員的我是否知道這一點，是否可以以某種方式優化我的程序的性能？ – Alex

當然，一個不知道他所運行的硬件的軟件開發人員在優化它（如果需要的話）或調試它（需要時:)方面做得不好。緩存映射地址類型確實有點低，儘管它爲一些重要的優化（如SW預取內在函數和緩存感知設計）打開了一扇門。看到這個偉大的職位的例子 - http://stackoverflow.com/questions/16699247/what-is-cache-friendly-code。另外還有無序執行的問題，可能會提供一些提示，當然還有各種編譯器優化（不是HW，但也很重要） – Leeor

我的意思是 - 從x86中的知識中受益：「它們是物理標記和虛擬索引「 – Alex

處理器x86/x86_64中是否使用物理或虛擬尋址在L1，L2和L3中緩存？

回答

相關問題