寫時復制技術（一下簡稱COW）是linux內核比較重要的一種機制，我們都知道：父行程fork子行程的時候，子行程會和父行程會以只讀的方式共享所有私有的可寫頁，當有一方將要寫的時候會發生COW缺頁例外，那么究竟COW在linux內核中是如何觸發？又是如何處理的呢？我們將在本文中以源代碼情景分析的方式來解讀神秘的寫時COW，從源代碼級別的角度徹底理解它，
需要說明的是:本文中所分析的內核原始碼時linux-5.0版本內核，使用arm64處理器架構，當然此文章發布時linux內核已經是linux-5.8.x，當你查看最新的內核原始碼的時候會發現變化并不是很大，本文主要會從下面幾個方面去分析討論寫時復制：
- fork子行程時內核為COW做了哪些準備
- COW行程是如何觸發的
- 內核時怎樣處理COW這種缺頁例外的
- 匿名頁的reuse
一，從fork說起
我們都知道，行程是通過fork進行創建的，fork創建子行程的時候會和父行程共享資源，如fs,file,mm等等，其中記憶體資源的共享是一下路徑：
kernel/fork.c
_do_fork->copy_process->copy_mm
當然本文中討論的是COW，暫時不詳解其他資源共享以及記憶體資源共享的其他部分（后面的相關文章我們會討論），copy_mm總體來說所作的作業是：分配mm_struct結構實體mm，拷貝父行程的old_mm到mm,創建自己的pgd頁全域目錄，然后會遍歷父行程的vma鏈表為子行程建立vma鏈表（如代碼段，資料段等等），然后就是比較關鍵的頁的共享，linux內核為了效率考慮并不是拷貝父行程的所有物理頁內容，而是通過復制頁表來共享這些頁，而在復制頁表的時候，內核會判斷這個頁表條目是完全復制還是修改為只讀來為COW缺頁做準備，
共享父行程記憶體資源處理如下：
以下我們主要分析copy_one_pte 拷貝頁表條目的這一函式：
首先會處理一些頁表項不為空但物理頁不在記憶體中的情況（!pte_present(pte)分支）如被swap到交換磁區中的頁，接下來處理物理頁在記憶體中的情況：
773 /*
774 |* If it's a COW mapping, write protect it both
775 |* in the parent and the child
776 |*/
777 if (is_cow_mapping(vm_flags) && pte_write(pte)) {//vma為私有可寫 而且pte有可寫屬性
778 ptep_set_wrprotect(src_mm, addr, src_pte);//設定父行程頁表項為只讀
779 pte = pte_wrprotect(pte); //為子行程設定只讀的頁表項值
780 }
781
上面的代碼塊是判斷當前頁所在的vma是否是私有可寫的屬性而且父行程頁表項是可寫：
247 static inline bool is_cow_mapping(vm_flags_t flags)
248 {
249 return (flags & (VM_SHARED | VM_MAYWRITE)) == VM_MAYWRITE;
250 }
如果判斷成立說明是COW的映射，則需要將父子行程頁表修改為只讀：
ptep_set_wrprotect(src_mm, addr, src_pte)將父行程的頁表項修改為只讀， pte = pte_wrprotect(pte)將子行程的即將寫入的頁表項值修改為只讀（注意：修改之前pte為父行程原來的pte值，修改之后子行程pte還沒有寫入到對應的頁表項條目中！）
修改頁表項為只讀的核心函式為：
152 static inline pte_t pte_wrprotect(pte_t pte)
153 {
154 pte = clear_pte_bit(pte, __pgprot(PTE_WRITE));//清可寫位
155 pte = set_pte_bit(pte, __pgprot(PTE_RDONLY));//置位只讀位
156 return pte;
157
再次回到copy_one_pte函式往下分析：
上面我們已經修改了父行程的頁表項，也獲得了子行程即將寫入的頁表項值pte(注意：現在還沒有寫入到子行程的頁表項中，因為此時子行程的頁表項值還沒有被完全拼接號好)，接下來我們將要拼接子行程的頁表項的值：
782 /*
783 |* If it's a shared mapping, mark it clean in
784 |* the child
785 |*/
786 if (vm_flags & VM_SHARED) //vma的屬性為共享
787 pte = pte_mkclean(pte);//設定頁表項值為clean
788 pte = pte_mkold(pte); //設定頁表項值為未被訪問過即是清PTE_AF
789
790 page = vm_normal_page(vma, addr, pte); //獲得pte對應的page結構（即是和父行程共享的頁描述符）
791 if (page) {
792 get_page(page);//增進page結構的參考計數
793 page_dup_rmap(page, false);//注意：不是拷貝rmap 而是增加page->_mapcount計數（頁被映射計數）
794 rss[mm_counter(page)]++;
795 } else if (pte_devmap(pte)) {
796 page = pte_page(pte);
797
798 /*
799 |* Cache coherent device memory behave like regular page and
800 |* not like persistent memory page. For more informations see
801 |* MEMORY_DEVICE_CACHE_COHERENT in memory_hotplug.h
802 |*/
803 if (is_device_public_page(page)) {
804 get_page(page);
805 page_dup_rmap(page, false);
806 rss[mm_counter(page)]++;
807 }
808 }
809
810 out_set_pte:
811 set_pte_at(dst_mm, addr, dst_pte, pte);//將拼接的頁表項值寫入到子行程的頁表項中
812 return 0;
以上程序就完成了對于需要寫時復制的頁，將父子行程的頁表項改寫為只讀（這時候vma的屬性是可寫的），并共享相同的物理頁，這為下面的COW缺頁例外做好了頁表級別的準備作業，
二，COW缺頁例外觸發條件
當然如果父子行程僅僅是對COW共享的頁面做只讀訪問，則通過各自的頁表就能直接訪問到對應的資料，一切都正常，一旦有一方去寫，就會發生處理器例外，處理器會判斷出是COW缺頁例外：
arm64處理器處理程序：
我們從handle_pte_fault函式開始分析：
3800 if (vmf->flags & FAULT_FLAG_WRITE) {//vam可寫
3801 if (!pte_write(entry))//頁表項屬性只讀
3802 return do_wp_page(vmf);//處理cow
3803 entry = pte_mkdirty(entry);
3804 }
程式走到上面的判斷說明：頁表項存在，物理頁存在記憶體，但是vma是可寫，pte頁表項是只讀屬性（這就是fork的時候所作的準備），這些條件也是COW缺頁例外判斷的條件，
三,發生COW缺頁例外
當內核判斷了這次例外時COW缺頁例外，就會呼叫do_wp_page進行處理：
2480 static vm_fault_t do_wp_page(struct vm_fault *vmf)
2481 __releases(vmf->ptl)
2482 {
2483 struct vm_area_struct *vma = vmf->vma;
2484
2485 vmf->page = vm_normal_page(vma, vmf->address, vmf->orig_pte);//獲得例外地址對應的page實體
2486 if (!vmf->page) {
2487 /*
2488 |* VM_MIXEDMAP !pfn_valid() case, or VM_SOFTDIRTY clear on a
2489 |* VM_PFNMAP VMA.
2490 |*
2491 |* We should not cow pages in a shared writeable mapping.
2492 |* Just mark the pages writable and/or call ops->pfn_mkwrite.
2493 |*/
2494 if ((vma->vm_flags & (VM_WRITE|VM_SHARED)) ==
2495 | (VM_WRITE|VM_SHARED))
2496 return wp_pfn_shared(vmf);//處理共享可寫映射
2497
2498 pte_unmap_unlock(vmf->pte, vmf->ptl);
2499 return wp_page_copy(vmf);//處理私有可寫映射
2500 }
2485行，獲得發生例外時地址所在的page結構，如果沒有page結構是使用頁幀號的特殊映射，則通過wp_pfn_shared處理共享可寫映射，wp_page_copy處理私有可寫映射，當然這不是我們分析重點，
我們繼續往下分析：
我們主要關注2522行，判斷是否可以重新使用這個頁，這個稍后在分析，
2544 |* Ok, we need to copy. Oh, well..
2545 |*/
2546 get_page(vmf->page);
2547
2548 pte_unmap_unlock(vmf->pte, vmf->ptl);
2549 return wp_page_copy(vmf);
2546行 增加原來的頁的參考計數，防止被釋放，
2548行 釋放頁表鎖
2549行 這是COW處理的核心函式
我們下面將詳細分析wp_page_copy函式：
* - Allocate a page, copy the content of the old page to the new one.
2234 * - Handle book keeping and accounting - cgroups, mmu-notifiers, etc.
2235 * - Take the PTL. If the pte changed, bail out and release the allocated page
2236 * - If the pte is still the way we remember it, update the page table and all
2237 * relevant references. This includes dropping the reference the page-table
2238 * held to the old page, as well as updating the rmap.
2239 * - In any case, unlock the PTL and drop the reference we took to the old page.
2240 */
2241 static vm_fault_t wp_page_copy(struct vm_fault *vmf)
2242 {
2243 struct vm_area_struct *vma = vmf->vma;
2244 struct mm_struct *mm = vma->vm_mm;
2245 struct page *old_page = vmf->page;
2246 struct page *new_page = NULL;
2247 pte_t entry;
2248 int page_copied = 0;
2249 struct mem_cgroup *memcg;
2250 struct mmu_notifier_range range;
2251
2252 if (unlikely(anon_vma_prepare(vma)))
2253 goto oom;
2254
2255 if (is_zero_pfn(pte_pfn(vmf->orig_pte))) {
2256 new_page = alloc_zeroed_user_highpage_movable(vma,
2257 | vmf->address);
2258 if (!new_page)
2259 goto oom;
2260 } else {
2261 new_page = alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma,
2262 vmf->address);
2263 if (!new_page)
2264 goto oom;
2265 cow_user_page(new_page, old_page, vmf->address, vma);
2266 }
2252行 關聯一個anon_vma實體到vma
2255行 到 2259行 判斷原來的頁表項映射的頁是0頁，就分配高端可移動的頁并用0初始化
2261到2265行 如果不是0頁，分配高端可移動的頁，然后將原來的頁拷貝到新頁
2268 if (mem_cgroup_try_charge_delay(new_page, mm, GFP_KERNEL, &memcg, false))
2269 goto oom_free_new;
2270
2271 __SetPageUptodate(new_page);
2272
2273 mmu_notifier_range_init(&range, mm, vmf->address & PAGE_MASK,
2274 (vmf->address & PAGE_MASK) + PAGE_SIZE);
2275 mmu_notifier_invalidate_range_start(&range);
2276
2277 /*
2278 |* Re-check the pte - we dropped the lock
2279 |*/
2280 vmf->pte = pte_offset_map_lock(mm, vmf->pmd, vmf->address, &vmf->ptl);
2281 if (likely(pte_same(*vmf->pte, vmf->orig_pte))) {
2282 if (old_page) {
2283 if (!PageAnon(old_page)) {
2284 dec_mm_counter_fast(mm,
2285 mm_counter_file(old_page));
2286 inc_mm_counter_fast(mm, MM_ANONPAGES);
2287 }
2288 } else {
2289 inc_mm_counter_fast(mm, MM_ANONPAGES);
2290 }
2291 flush_cache_page(vma, vmf->address, pte_pfn(vmf->orig_pte));
2292 entry = mk_pte(new_page, vma->vm_page_prot);
2293 entry = maybe_mkwrite(pte_mkdirty(entry), vma);
2294 /*
2295 |* Clear the pte entry and flush it first, before updating the
2296 |* pte with the new entry. This will avoid a race condition
2297 |* seen in the presence of one thread doing SMC and another
2298 |* thread doing COW.
2299 |*/
2300 ptep_clear_flush_notify(vma, vmf->address, vmf->pte);
2301 page_add_new_anon_rmap(new_page, vma, vmf->address, false);
2302 mem_cgroup_commit_charge(new_page, memcg, false, false);
2303 lru_cache_add_active_or_unevictable(new_page, vma);
2304 /*
2305 |* We call the notify macro here because, when using secondary
2306 |* mmu page tables (such as kvm shadow page tables), we want the
2307 |* new page to be mapped directly into the secondary page table.
2308 |*/
2309 set_pte_at_notify(mm, vmf->address, vmf->pte, entry);
2310 update_mmu_cache(vma, vmf->address, vmf->pte);
2311 if (old_page) {
2312 /*
2313 |* Only after switching the pte to the new page may
2314 |* we remove the mapcount here. Otherwise another
2315 |* process may come and find the rmap count decremented
2316 |* before the pte is switched to the new page, and
2317 |* "reuse" the old page writing into it while our pte
2318 |* here still points into it and can be read by other
2319 |* threads.
2320 |*
2321 |* The critical issue is to order this
2322 |* page_remove_rmap with the ptp_clear_flush above.
2323 |* Those stores are ordered by (if nothing else,)
2324 |* the barrier present in the atomic_add_negative
2325 |* in page_remove_rmap.
2326 |*
2327 |* Then the TLB flush in ptep_clear_flush ensures that
2328 |* no process can access the old page before the
2329 |* decremented mapcount is visible. And the old page
2330 |* cannot be reused until after the decremented
2331 |* mapcount is visible. So transitively, TLBs to
2332 |* old page will be flushed before it can be reused.
2333 |*/
2334 page_remove_rmap(old_page, false);
2335 }
2336
2337 /* Free the old page.. */
2338 new_page = old_page;
2339 page_copied = 1;
2340 } else {
2341 mem_cgroup_cancel_charge(new_page, memcg, false);
2342 }
2271行 設定新的頁標識位為PageUptodate，表示頁中包含有效資料，
2280行 鎖住頁表
2281到2339行是發生缺頁例外時獲得頁表項和現在鎖住之后獲得頁表項內容相同的情況
2341 時頁表項不同的情況
主要分析相同的情況：
2282到2290 主要時對頁計數的統計
2291 cache中重繪頁
2292行 由vma的訪問權限和新頁的頁描述符來構建頁表項的值
2293行 設定頁表項值屬性為臟和可寫（如果vma有可寫屬性，這個時候將頁表項修改為了可寫，fork的時候修改為只讀這個地方修改了回來）
2300行 將頁表項原有的值清除，然后重繪地址發生缺頁地址對應的tlb（這一行操作很重要）
2301行 將新的物理頁添加到vma對應的匿名頁的反向映射中
2303行 將新物理頁添加到活躍或不可回收LRU鏈表中
2309 行將構建好的頁表項值寫入到頁表項條目中，這個時候頁表項修改才會生效，
2334行 洗掉原來的頁到虛擬頁的反向映射，然后做了比較重要的一個操作為atomic_add_negative(-1, &page->_mapcount)將頁的頁表映射計數減一，
2344到2347 遞減舊頁的參考計數 并釋放頁表鎖
2353到2364行 如果已經映射了新的物理頁，舊頁被鎖住在記憶體中，將舊頁解鎖，
到此就完成了寫時復制程序，總結下：分配新的物理頁，拷貝原來頁的內容到新頁，然后修改頁表項內容指向新頁并修改為可寫（vma具備可寫屬性），
前面我們遺留了一個問題沒有討論，那就是do_wp_page函式中處理reuse_swap_page的處理，所謂的單身匿名頁面的處理，
四，匿名頁的reuse
假設有如下情形發生：父行程P通過fork創建了子行程A,其中有一私有可寫的匿名頁page1被共享，這個時候內核會此頁都映射到各自的虛擬記憶體頁，并修改雙方的頁表屬性為只讀，page1的映射計數_mapcount為2， 這個時候假設子行程寫page1,則發生COW例外，例外處理程式為子行程A分配了新頁page2并和虛擬頁建立映射關系，并改寫了子行程頁表項為可寫，這個時候子行程可以隨意的寫page2而不會影響父行程，當然上面分析我們知道page1的映射計數_mapcount會遞減1變為1，也就表面這個頁page1被父行程所唯一映射，那么這個時候父行程再去寫page1，會發生什么呢？還會發生COW去分配新的頁嗎?
下面我們在源代碼中尋找答案：
do_wp_page函式的2502到2541是我們分析重點：
2502 /*
2503 |* Take out anonymous pages first, anonymous shared vmas are
2504 |* not dirty accountable.
2505 |*/
2506 if (PageAnon(vmf->page) && !PageKsm(vmf->page)) {
2507 int total_map_swapcount;
2508 if (!trylock_page(vmf->page)) {
2509 get_page(vmf->page);
2510 pte_unmap_unlock(vmf->pte, vmf->ptl);
2511 lock_page(vmf->page);
2512 vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd,
2513 vmf->address, &vmf->ptl);
2514 if (!pte_same(*vmf->pte, vmf->orig_pte)) {
2515 unlock_page(vmf->page);
2516 pte_unmap_unlock(vmf->pte, vmf->ptl);
2517 put_page(vmf->page);
2518 return 0;
2519 }
2520 put_page(vmf->page);
2521 }
2522 if (reuse_swap_page(vmf->page, &total_map_swapcount)) {
2523 if (total_map_swapcount == 1) {
2524 /*
2525 |* The page is all ours. Move it to
2526 |* our anon_vma so the rmap code will
2527 |* not search our parent or siblings.
2528 |* Protected against the rmap code by
2529 |* the page lock.
2530 |*/
2524 /*
2525 |* The page is all ours. Move it to
2526 |* our anon_vma so the rmap code will
2527 |* not search our parent or siblings.
2528 |* Protected against the rmap code by
2529 |* the page lock.
2530 |*/
2531 page_move_anon_rmap(vmf->page, vma);
2532 }
2533 unlock_page(vmf->page);
2534 wp_page_reuse(vmf);
2535 return VM_FAULT_WRITE;
2536 }
2537 unlock_page(vmf->page);
2538 } else if (unlikely((vma->vm_flags & (VM_WRITE|VM_SHARED)) ==
2539 (VM_WRITE|VM_SHARED))) {
2540 return wp_page_shared(vmf);
2541 }
2506行 對于匿名頁面且非KSM頁
2522行 判斷是否這個頁面只被我所擁有（total_map_swapcount <= 0）
2534 呼叫wp_page_reuse處理（這是重點）
2195 /*
2196 * Handle write page faults for pages that can be reused in the current vma
2197 *
2198 * This can happen either due to the mapping being with the VM_SHARED flag,
2199 * or due to us being the last reference standing to the page. In either
2200 * case, all we need to do here is to mark the page as writable and update
2201 * any related book-keeping.
2202 */
2203 static inline void wp_page_reuse(struct vm_fault *vmf)
2204 __releases(vmf->ptl)
2205 {
2206 struct vm_area_struct *vma = vmf->vma;
2207 struct page *page = vmf->page;
2208 pte_t entry;
2209 /*
2210 |* Clear the pages cpupid information as the existing
2211 |* information potentially belongs to a now completely
2212 |* unrelated process.
2213 |*/
2214 if (page)
2215 page_cpupid_xchg_last(page, (1 << LAST_CPUPID_SHIFT) - 1);
2216
2217 flush_cache_page(vma, vmf->address, pte_pfn(vmf->orig_pte));
2218 entry = pte_mkyoung(vmf->orig_pte);
2219 entry = maybe_mkwrite(pte_mkdirty(entry), vma);
2220 if (ptep_set_access_flags(vma, vmf->address, vmf->pte, entry, 1))
2221 update_mmu_cache(vma, vmf->address, vmf->pte);
2222 pte_unmap_unlock(vmf->pte, vmf->ptl);
2223 }
代碼中可以清晰看到：
2218行 設定頁被訪問
2219行 設定頁表項為臟，如果頁所在的vma是可寫屬性則設定頁表項值為可寫
2220行 將設定好的頁表項值寫入到頁表項條目中（真正設定好了頁表項），注意arm64中在ptep_set_access_flags重繪了頁對應的tlb，
分析到這里，有關COW的機制已經全部分析完，當然這個程序涉及到了無數的技術細節，在此不再一一贅述，后面有機會會討論到相關的內容，
五，總結
我們總結一下寫時復制（COW）機制的整個程序：首先發生在父行程fork子行程的時候，父子行程會共享（此共享并不是我們通常所說的共享映射和私有映射，而是通過將頁映射到每個行程頁表形成共享）所有的私有可寫的物理頁，并將父子行程對應的頁表項修改為只讀，當有一方試圖寫共享的物理頁，由于頁表項屬性是只讀的會發生COW缺頁例外，缺頁例外處理程式會為寫操作的一方分配新的物理頁，并將原來共享的物理頁內容拷貝到新頁，然后建立新頁的頁表映射關系，這樣寫操作的行程就可以繼續執行，不會影響另一方，父子行程對共享的私有頁面訪問就分道揚鑣了，當共享的頁面最終只有一個擁有者（即是其他映射頁面到自己頁表的行程都發生寫時復制分配了新的物理頁），這個時候如果擁有者行程想要寫這個頁就會重新使用這個頁而不用分配新頁，
下面給出實驗代碼案例：
程式中有一全域變數num=10 列印num的值, 然后fork子行程，在子行程中修改全域變數num=100 然后列印num的值,父行程中睡眠1s故意等待子行程先執行完， 然后再次列印num的值
1 #include <stdio.h>
2 #include <unistd.h>
3 #include <sys/types.h>
4
5
6 int num = 10;
7
8 int main(int argc,char **argv)
9 {
10
11 pid_t pid;
12
13 printf("###%s:%d pid=%d num=%d###\n", __func__, __LINE__, getpid(), num);
14
15
16 pid = fork();
17 if (pid < 0) {
18 printf("fail to fork\n");
19 return -1;
20 } else if (pid == 0) { //child process
21 num = 100;
22 printf("### This is child process pid=%d num=%d###\n", getpid(), num);
23 _exit(0);
24 } else { //parent process
25 sleep(1);
26 printf("### This is parent process pid=%d num=%d###\n", getpid(), num);
27 _exit(0);
28 }
29
30 return 0;
31 }
大家可以思考一下：第13，22, 27分別得出的num是多少？
我們編譯執行：
hanch@hanch-VirtualBox:~/test/COW$ gcc fork-cow-test.c -o fork-cow-test
hanch@hanch-VirtualBox:~/test/COW$ ./fork-cow-test
###main:13 pid=26844 num=10###
### This is child process pid=26845 num=100###
### This is parent process pid=26844 num=10###
可以發現父行程中的全域變數num =10, 當fork子行程后對這個全域變數進行了修改使得num =100,實際上fork的時候已經將父子行程的num這個全域變數所在的頁修改為了只讀，然后共享這個頁，當子行程寫這個全域變數的時候發生了COW缺頁例外，然而這對于應用程式來說是透明的，內核卻在缺頁例外處理中做了很多作業：主要是為子行程分配物理頁，將父行程的num所在的頁內容拷貝到子行程，然后將子行程的va所對應的的頁表條目修改為可寫和分配的物理頁建立了映射關系，然后缺頁例外就回傳了（從內核空間回傳到了用戶空間），這個時候處理器會重新執行賦值操作指令，這個時候屬于子行程的num才被改寫為100，但是要明白這個時候父行程的num變數所在的頁的讀寫屬性還是只讀，父行程再去寫的時候依然會發生COW缺頁例外，
最后我們用圖說話來理解COW的整個程序：
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/201.html
標籤：嵌入式
下一篇：高通平臺底電流調節心得