本文是回答一位同事問到的，關(guān)于有多個核運行一個或者多個進程的時候，MMU和ASID怎么應(yīng)用的問題。

復(fù)雜的問題總是來自簡單問題的組合，所以，我們還是從最基本的概念開始建模。

MMU是CPU的地址翻譯器，每個CPU一個，示意如下：

你從全系統(tǒng)看，pa只有一份，而每個cpu都有自己的一份va，翻譯方法由頁表指定，放在物理內(nèi)存里面，TLB充當(dāng)這個頁表內(nèi)存的Cache，把常用的翻譯項內(nèi)置在MMU中。這是硬件角度提供的模型。

好，現(xiàn)在看軟件怎么用。假設(shè)我創(chuàng)建一個進程，我把它部署到左邊的CPU上。我要設(shè)定這個進程的頁表空間，它就是這樣的：

如果你在另一個CPU上再創(chuàng)建一個進程，就是把左邊的事情再做一次，這個我們就不畫圖了。

如果你現(xiàn)在要把左邊這個CPU的進程切換出去，交給另一個進程，就會這樣：

進程1暫時放一邊，頁表換成進程2的頁表就行。但這個過程成本很高，因為你首先得把TLB里面屬于進程1頁表的緩沖清掉，才能保證不會影響進程2的地址空間。

為了解決這個問題，我們把每個翻譯條目都加上一個進程ID，簡稱ASID。在CPU的系統(tǒng)寄存器中設(shè)置上這個ASID，這樣進程1用進程1的asid，進程2用進程2的asid，兩者都在TLB中，但進程2占據(jù)CPU的時候，不會使用進程1的項，等切換回進程1的時候，原來的東西還在，也不需要重新加載，這提高了效率。

我們當(dāng)然想最好asid和軟件的pid是一樣的，但一般做不到，因為軟件的PID通常是一個標(biāo)準(zhǔn)字長，而asid必須嵌入頁表項里，沒法放太大，所以，它常常只有16位，甚至8位之類的，需要一個稀疏映射表才能把兩者關(guān)聯(lián)起來。

現(xiàn)在假設(shè)我在左邊CPU的進程中再創(chuàng)建一個線程，而且把這個線程調(diào)度到第二個CPU上，這個結(jié)果是這樣的：

兩個CPU共享同一個進程，它們就需要共享同一個頁表，但它們需要共享同一個asid嗎？答案是：不需要。因為asid本來就不大，明明可以分開用，只要達(dá)到每個CPU的調(diào)度上限就可以了，你現(xiàn)在讓我公用？如果有一個進程永遠(yuǎn)不調(diào)度到我這邊，我不是虧（白分配）了？

所以，靠譜的實現(xiàn)（比如Linux Kernel）中，asid僅在本CPU有效，擴展到IOMMU，也僅僅對那個設(shè)備有效，不是全局的。所以，對于每個進程的asid，都是per_cpu結(jié)構(gòu)，每個CPU都有一個實例。

有趣的而是，RISC-V的20190608-Priv-MSU-Ratified版本里面有這樣一條修改記錄：Software is strongly recommended to allocate ASIDs globally, so that a future extension can globalize ASIDs for imporved performance and hardware flexibility。做這個統(tǒng)一對軟件來說未來表面上肯定是利好的，因為很多方案多了一個假設(shè)可以用。但綜合性能是否能夠做上去，還真要用上一段時間才知道。

這時，如果其中一個CPU進行調(diào)度，把時間讓給另一個進程，結(jié)果就會是這樣的：

TLB里面誰的頁表都可以有，反正有asid區(qū)分，有一個線程被掛起，以后屬于哪個CPU等調(diào)度的時候另說，剩下就是誰占著那個CPU，誰在那個CPU上的asid生效，自然就會查那個asid的翻譯項，如果沒有，就從真正的內(nèi)存頁表里面讀進去了。

如果進程實在太多，在某個CPU上沒法給他分配一個實在的了，這個好辦，只要分配一個不是當(dāng)前的，然后把新分配的這個asid的內(nèi)容從TLB里面全部抹掉就可以了。代碼在各個平臺的上下文切換邏輯中，比如ARM64，代碼在arch/arm64/mm/context.c中。但其實概念空間邏輯都是一樣的。

Linux在實現(xiàn)的時候用了大量的Lazy算法，所以，其實asid都不是在進程創(chuàng)建的時候生成的，而是在調(diào)度前發(fā)現(xiàn)沒有了，就臨時生成的，這對于新手來說，看代碼會比較困擾的，但還是那句話，習(xí)慣就好。