背景：
平臺：stm32mp151平臺
什么是OTA？
說起OTA我們應該都不陌生，它是一種可以為設備無損失升級系統的方式，能將新功能遠程部署到產品上。
我們不僅可以通過網絡下載OTA升級包，也可以通過下載OTA升級包到SD卡或U盤后再對設備升級。
OTA下載方式：
- 短信方式
- PUSH方式
- 網絡定制
本例網絡定制方式。
現象描述
本產品通過OTA升級測試，升級162次，死機重啟19次，如下圖所示：
死機重啟分析：
1. 為何oom會導致重啟？
當需要申請物理頁面時，首先使用快通道申請頁面，當快通道申請不到將會進入慢通道，當慢通道也無法申請是將觸發oom-killer,正常情況下會殺死消耗物理頁面最多的進程，而設備直接進入PANIC然后重啟。當申請物理頁面時free頁面很多情況也會存在頁面申請失敗的現象，一方面可能內存外碎片化嚴重，另一方面可能是無法借用其他遷移類型內存。因此盡量不要使能panic_on_oom，但設備使能該參數，如下圖所示：
若去掉使能選項，oom-killer將會殺掉物理頁最大進程，因此應該殺死藍牙進程，在升級過程中，殺掉藍牙進程對業務無任何影響。下圖為不開啟參數而殺掉最大物理頁進程：
2. 為何free頁面很多但是還是會進入oom？
當前我們已經知道因/proc/sys/vm/panic_on_oom=1 導致進入oom后便會panic然后重啟，但為何內存不足呢？我們的日志提示還有126M物理頁處于空閑可用，不應該會進入內存申請失敗的情況。
細看可知gfp_mask=0x101cc0，則MIGRATE_MOVABLE未置1，導致ALLOC_CMA未置1，既不允許使用cma_pages,
當CMA頁面不允許使用時，實際所剩余可申請的頁面數：free減去free_cma,free_cma提示120多M（高達實際物理內存一半）,所以剩余非遷移屬性的頁面只剩幾M:
解決措施：
因此除了關閉panic_on_oom，還應該去查查為何free_cma為何可以分配的那么多,而不做最大值限制，通過啟動日志可看出系統CMA的最大限制為128M，如下圖所示：
CMA我們分配竟然達到了50%物理內存，因此將CMA降成64M大小，以釋放64M用于非遷移屬性頁面申請。通過uboot傳參cma=64M,可將cma最大值設置為64M。
