記憶體碎片對相機性能的影響

這里說的碎片是物理記憶體碎片，而且是外部碎片問題，先說下為什么要關注記憶體碎片，因為手機系統的記憶體碎片嚴重會對相機性能帶來了如下不好的影響：

1: 首先是相機的記憶體分配性能會受影響，會變得耗時很多，

具體體現在相機發出大塊連續物理記憶體(order>0)分配需求時，會受阻，會長時間陷入到direct reclaim中，

相機場景下，ion和gpu記憶體分配, 創建子執行緒分配內核堆疊操作等都有這種連續物理記憶體分配需求，

2: kswapd和kcompactd會例外活躍，會時常跑到cpu大核上跟前臺相機行程搶占cpu資源，干擾相機的正常運行，

之前wiki:手機kswapd活躍原因調查里面調研過大部分相機場景下，kswapd頻繁活躍原因是：記憶體碎片化，

為什么記憶體碎片會帶來性能問題

記憶體碎片從表面上看是正常的

隨著系統的運行，頁面被分配給各種任務，隨著時間的推移記憶體會逐步碎片化，最終正常運行時間較長的繁忙系統可能只有很少的物理頁面是連續的，

由于 Linux 內核支持虛擬記憶體管理，物理記憶體碎片通常不是問題，因為在頁表的幫助下，物理上分散的記憶體在虛擬地址空間仍然是連續的 （除非使用大頁），

結論：

有了mmu和虛擬記憶體的存在，行程用戶態的記憶體分配和管理不太需要關注物理記憶體碎片，因為我用戶態cpu尋址的始終是一片平坦大片連續的虛擬記憶體，

你有物理記憶體碎片，我頂多實際訪問那片虛擬記憶體時，一個缺頁例外下去只需要分配出一個物理page，然后眾多的離散物理page拼接在一起就可以了，

其實性能問題出在內核態

內核態經常會有連續物理記憶體分配需求, 所以物理記憶體碎片嚴重時，這種分配需求就會受阻，就會出性能問題，

主要的分配需求來自于內核線性映射區，

這個區域常見的分配需求有常見的內核kmalloc, slab分配，新創建行程執行緒的內核堆疊分配，還有其他的模塊，比如檔案系統里面不想用vmalloc的那些分配等，這些都會大量發出高階(order>0)物理記憶體分配需求，

一旦滿足不了需求，內核堆疊分配耗時會導致相機創建子執行緒耗時，kmalloc和檔案系統里面記憶體分配耗時會導致相機寫檔案存圖耗時，

為什么要搞線性映射區，為什么這些分配不能像用戶態那樣搞成離散物理page拼接分配，還非得要搞成連續物理記憶體分配

首先arm64平臺上，線性映射區不僅搞成了，而且空間很大，從從ffff000000000000到ffff7fffffffffff，最大支持128TB的物理地址空間，這樣android上肯定可以映射整個物理記憶體空間了，還不像在32位系統上（物理記憶體較少的系統除外），只有一部分物理記憶體可以映射，

線性映射區里面的order>0的物理記憶體分配，肯定得是連續的，

搞線性映射區和連續物理記憶體分配的目的：

內核態記憶體分配性能是系統最看重的

內核態記憶體頁表是系統所有行程共享的，內核態的記憶體分配屬于最基礎層面的作業，它的性能是系統最關注的，比用戶態記憶體分配還重要，用戶態記憶體還可以搞成延遲分配，并且記憶體不用時，可以被交換到zram中，內核態記憶體不行，

所以為了提升內核態記憶體分配性能，android/linux系統搞了個線性映射區,有如下好處：

1: 系統剛開機時，內核在初始化時，已經建立好了線性映射區的虛擬記憶體和物理記憶體映射關系，當然了，此時物理記憶體并未真正分配，但是映射關系建好了，

然后在往后的該區域內的物理記憶體分配時，就不需要再像vmalloc那樣，去費勁建立映射關系了（更改頁表有時候也比較緩慢），只需要專注于物理記憶體分配就行，搞到實際物理記憶體后，想讓cpu使用，直接用page_address -> page_to_virt宏就能轉換成虛擬地址了，

2: 如果系統分配連續的物理記憶體，則對應的線性地址一般也是連續的，這樣在多數情況下，連續的線性地址可以通過相同的頁目錄項、頁表來轉換成物理地址，這就提高了訪問TLB的命中率，同時，連續的物理地址也可以提高系統cache的命中率，

所以內核里面線性映射區要承擔很多內核記憶體分配作業，

然后還有相當一部分需求來自于相機場景下大量ion和gpu記憶體分配

ion和gpu由于dma實時傳輸大量資料的性能需求，也有分配連續物理記憶體的需求，即使現在器件進步有iommu了，

詳細見：kernel/msm-4.19/drivers/staging/android/ion/ion_heap.c

里面有order=9和=4的分配需求的,上面下發ion記憶體分配請求時，首先嘗試分配order=9或者4的大塊連續物理記憶體，分配不出來，才想到order=0的記憶體分配，

不過這部分連續物理記憶體搞到手后，有意思的是還會讓用戶空間行程去訪問到，做下remap_pfn_range或者pagefualt映射就可以了，

這部分物理記憶體分配沒有來自于內核線性映射區，但也是屬于內核態的記憶體分配，

產生性能問題的原因

假設系統里面都是用戶空間分配的記憶體，假設我要將某個直接頁表項中對應的物理頁面換走，只需要分配一個新頁面，將舊頁面的資料拷貝到新頁面，然后修改此直接直接頁表項的值為新的頁幀號即可，而不會改變原來的虛擬地址，

這樣的頁面是moveable的，可以隨便遷移的，所以如果內核有連續物理記憶體分配需求，即使碎片化嚴重，可以使用內核的記憶體compact功能，把眾多已分配頁面聚合到一起，那么剩下的依然還會有連續free物理記憶體空間可供分配，

但是問題出在：

對于線性映射區，虛擬地址 = 物理地址 + 常量，我們若修改物理地址，必然會導致虛擬地址也發生變化，所有繼續訪問原虛擬地址的行為就出 bug 了，這樣的頁面是unmoveable的，顯然不宜遷移，

當然還有上面的Ion,gpu驅動記憶體分配的也是unmoveable頁面，

所以當通過頁表訪問的物理頁面和通過線性映射的頁面混合在一起管理時，就很容易出現記憶體碎片，由于unmoveable頁面不能遷移，內核記憶體compact對它沒有用，

所以對于長時間運行的系統，unmoveable頁面離散并且多的時候，就出現嚴重的記憶體碎片，導致內核的連續物理記憶體分配請求受阻，

原生andorid的記憶體碎片優化方案介紹

一 頁面遷移型別優化

前面說了記憶體碎片是外部碎片問題，這個外部碎片其實就是內核buddy系統在分配物理記憶體時產生的，內核buddy系統也有一定的局限性，

buddy局限性

buddy的碎片防止機制寄托于記憶體使用者會及時釋放掉記憶體的情況，如果使用者長期不釋放記憶體，或者說在使用者還沒有釋放記憶體的這一段時間期間，碎片將是存在的，并且可能還會導致很大的問題，

比如在物理記憶體中間分配了一頁面，然而僅因為分配的這一個頁面不可移動，在它被釋放之前，系統可用的最大的連續物理記憶體就只有不到一半物理記憶體總大小了，

究其根源，這種問題的根源在于buddy系統僅僅釋放頁面時的合并操作防止了碎片的產生，不管頁面從哪里被分配，只要它能有效被釋放，碎片就是可以避免的，也就是說，buddy系統對于分配并沒有更多的約束，僅僅滿足在10個free_area中從小到大的順序掃描即可，

引入頁面遷移型別對其的改善

既然找到了buddy的問題，那么只要對分配動作采取一定的約束，碎片就可以進一步避免了，
最簡單而又不引入過多復雜性的辦法就是將頁面按照“可移動”屬性分類，將不可移動的頁面分為一類，將可以移動的頁面分為一類，它們各自占據一塊足夠大的連續物理空間，不可移動的頁面分配需求則盡量在它自己的頁面類中分配，可移動的頁面也一樣，

這樣一來，不可移動的頁面的不可移動性僅僅影響它自身的類別而不會導致一個不可移動的頁面兩邊都是可移動的頁面，這就是MIGRATE_TYPE被引入的目的，MIGRATE_TYPE限制了記憶體頁面的分配地點從而避免碎片，而不再僅僅寄希望于它們被釋放時通過合并避免碎片，

具體實施時需要考慮的因素：
1：可以說MIGRATE_TYPE僅僅是一種防止碎片的策略，不應該因為它的存在而影響到記憶體分配的結果，也就是說，如果在一個MIGRATE_TYPE鏈表中沒有記憶體可以分配了，那么也還是可以從別的鏈表中“暫時搶”一些的（對應內核的__rmqueue_fallback函式），搶的時候，不是搶剛好夠用的，而是一次盡量搶一個page block（伙伴系統所能容納的最大連續物理記憶體）, 只有一次性分配一大塊記憶體，才不至于引入碎片，

2：另外，還有一個問題，內核載初始化的時候如何為“不可移動類”或者“可移動類”頁面指定初始大小呢？也就是說，一開始，系統的free_area中的這些類別鏈表的頁面各該是多少個呢？

　事實上，內核從來沒有指定過初始大小，而是一開始將所有頁面都歸到“可移動”組當中，而別的組全部都是空的，等到真的有不可移動頁面需求的時候再從可移動組中撥一批給不可移動組鏈表，想一下這也是合理的，畢竟只是一些“不可移動”的頁面造成了記憶體的長期碎片化，如果沒有這些長期使用的不可移動頁面，碎片的問題是不大的，

二 Migrate_highatomic的推出

Migratetype具體使用時的一點坑

記憶體碎片化嚴重或者有碎頁問題時，會發現系統中記憶體頁面有很多都是unmoveable頁面，

而應用層都是申請的一個一個的moveable頁面,發現申請不到，也不好去steal，所以系統中很多都是Unmoveable頁面，

Migrate_highatomic對于抗碎頁的好處

這個Migrate_highatomic是新增加的一個頁面遷移型別，好處是如果分配Migrate_highatomic型別的頁面時，分配不到時，不會去steal，分配到時，會呼叫reserve_highatomic_pageblock直接去搞出來一個大的pageblock頁塊（有點像ion page pool）,就是本次多分配些，避免下次再分配再產生記憶體碎片，

當系統記憶體緊張時，之前reserved的還會被釋放的，然后其他Migratetype的不會到這個型別頁面去steal,避免相互steal的影響，

目前內核中限制只有gfp_flags為__GFP_ATOMIC型別的分配，才會有可能走Migrate_highatomic型別的頁面分配路徑，才會發揮出Migrate_highatomic抗碎頁的好處，

當前在中斷、軟中斷、spinlock等原子背景關系里面，申請記憶體，都會使用GFP_ATOMIC標記，意思是此背景關系不能睡眠，譬如內核中有大量的kmalloc/GFP_ATOMIC的例子，

另外一些緊急在記憶體緊急的路徑上（比如不想睡眠，或者是對于前臺app的一些記憶體分配，要求低延遲，對性能敏感)，哪怕是行程背景關系，我們也建議可以考慮使用GFP_ATOMIC，

三 高通ion page pool優化

其實思路跟上面的Migrate_highatomic有點類似，前面講了ion驅動里面申請的記憶體頁面都是unmoveable的，更容易造成碎片問題，那好辦，直接再加個快取池，

系統記憶體充足或者壓力小時，就相機每次分配完ion記憶體后，就會觸發下該快取池的蓄水作業，會在系統里面再搞出很多連續free頁面(這個時候搞著也容易)，加到該池子里面，那么下次再分配ion記憶體時，直接從池子里面取，

這樣就帶來一個很大的好處：

每次ion記憶體分配都會聚合在一個地方(page pool)進行分配, unmoveable頁面都會聚合在一起，不會再發散地分布在系統記憶體各個地方，

然后等到系統的記憶體分配壓力大時，這個page pool里面的快取隨時都可以被釋放出來，滿足系統其他地方的記憶體分配請求，

這個是一個比較好的記憶體抗碎片的優化方案，詳見代碼：

kernel/msm-4.19/drivers/staging/android/ion/ion_page_pool.c

四 boost watermark方案優化

[PATCH 3/5] mm: Reclaim small amounts of memory when an external fragmentation event occurs

(該patch在8250r機型內核代碼中有)

watermark_boost_factor的推出，是為了降低external fragmentation event次數，這個次數等于內核mm_page_alloc_extfrag這個trace event事件的發生次數，

這個次數降低了，內核記憶體碎片問題也會減輕不少的，下面是推出該patch的來龍去脈，

kernel在降低外部碎片率的弊端

The kernel reduces the probability of such events by increasing the watermark sizes by calling set_recommended_min_free_kbytes early in the lifetime of the system.

This works reasonably well in general but if there is enough sparsely populated pageblocks then the problem can still occur as enough memory is free overall and kswapd stays asleep.

watermark_boost_factor的提出

This patch introduces a watermark_boost_factor sysctl that allows a zone watermark to be temporarily boosted when an external fragmentation causing events occurs.

The boosting will stall allocations below the boosted low watermark and kswapd is woken unconditionally to reclaim an amount of memory relative to the size of the high watermark and the watermark_boost_factor until the boost is cleared，

思路很簡單，就是常用的降低記憶體碎片的思路：

限制內核page cache使用，類似于提高vm.min_free_kbytes，雖然調大 vm.min_free_kbytes 確實會導致一些記憶體浪費，另外page cache減少，系統的io讀性能也會下降，

但性能優化就是這種針對不同的業務問題場景做折衷的，有些時候，比如旗艦手機總記憶體本身就大，記憶體充足，這個時候重點關注的是碎片化問題，那么就上boost watermark方案優化碎片，

watermark_boost_factor的優化

kswapd avoids any writeback or swap from reclaim context during this operation to avoid excessive system disruption in the name of fragmentation avoidance.

這個地方其實是做了快速回識訓制，限制boost watermark里面只回收干凈檔案頁，其他的臟頁，還有匿名頁就不回收了(因為回收這兩個很耗時)，這樣記憶體回收快了，由boost watermark而觸發的kswapd耗時會減少不少，

五 其他的抗碎片優化

１：最直接的內核態分配連續記憶體時，可以用類似vmalloc代替kmalloc, 避免連續物理記憶體分配需求，

２：現在設備也進步了，相機里面有了smmu，dma資料傳輸時，不再有硬性非得分配大塊連續物理記憶體的需求了，也可以一頁一頁地拼接了，但是這樣做每次分配都得map/umap，

而且還得一頁一頁從buddy里面去分配也很耗時的，尤其對于相機上層下發的>=2M dma資料傳輸需求，能一次搞到一大塊連續物理記憶體最好了，

３：zone_moveable

這個是個虛擬zone,它的提出開始是為了抗碎頁，把安卓那些highmem和moveable分配需求集中放到這個zone里面，從而使得這個zone里面都是可移動頁面，方便compact，

但是后來發現它有更好的用途 memhotplug,而原先的用途抗碎頁被更好的機制頁面遷移型別給取代了（況且用這個zone_moveable來抗碎頁也不好），

４：cma記憶體分配，

這個cma和上面的zone_movealbe在抗碎頁方面其實都有坑，

驅動需要cma時，分配不出連續物理記憶體頁面時，就要做很重的系統回收操作，影響性能，而且最后還有可能分配不出去，這個其實是跟內核記憶體回收狀態機做對抗的，

５：內核zram模塊，還有其他地方的unmoveable頁面變成moveable頁面，

其他記憶體碎片優化方案

1 禁止分配大塊unmoveable的連續物理記憶體

暫時保密，

2 周期性的記憶體compact觸發

暫時保密

3 結合網上搜的，我自己想的抗記憶體碎片優化方案

設計背景：

主要解決安卓系統長時間運行碎片化嚴重時，執行緒創建耗時問題，具體是因為執行緒在為內核堆疊分配連續物理記憶體時受阻，這個估計app冷啟動性能也會受影響，因為啟動時要創建大量執行緒出來，

具體代碼調研：

現在安卓系統，至少android新版本內核代碼，我看到CONFIG_VMAP_STACK配置項并未被開啟，而且內核堆疊占記憶體大小肯定是order>0的，這樣：

kernel/msm-4.19/kernel/fork.c
SYSCALL_DEFINE0(vfork)和kernel_thread（Create a kernel thread.） 都會呼叫_do_fork --> copy_process --> dup_task_struct --> alloc_thread_stack_node　--> alloc_pages_node里面分配連續物理記憶體就會受阻，

設計思路：

參看下面的朱輝優化patch, 把一些前臺關鍵app行程/執行緒的內核堆疊記憶體頁連續分配放到這個highatomic里面了，這樣至少在系統記憶體碎片化嚴重場合，在相機app冷啟動方面，肯定會有性能收益的，

Use HighAtomic against long-term fragmentation

https://lkml.org/lkml/2017/9/26/232

總結

內核在記憶體抗碎片方面的優化是歷史悠久的，印象中是從2005年就開始了，然后持續到現在，都在源源不斷在mm/{page_alloc.c vmscan.c}里面進抗碎片優化patch.

抗碎片是個內核記憶體分配方面的系統架構性的優化工程，里面優化方案牽涉面廣，而且優化背景也比較復雜，

所以涉及到篇幅問題，要想讓讀者對系統記憶體碎片化這個問題理解透徹，只能從全域入手，把握整體和要害，大概簡單通俗易懂的講些抗碎片方面的實作原理和輪廓，再進一步詳細的還得看代碼理解，

當理解了內核在記憶體抗碎片方面做的努力，就理解了內核記憶體管理至少40%的代碼，