Android的LMK機制學習筆記

一、文章背景

????最近在分析一個應用進后臺經常被殺死問題，問題發生在一個定制的系統中，存在多個內存動態清理工具（類似手機衛士等工具，是廠商開發的預裝應用，具備內存不足時的進程查殺能力）。于是需要逐一排查，最終定位到是被Android系統的LMK機制kill掉的，但是因為對于LMK機制的不熟悉，導致定位了兩天時間，這里做一個學習筆記以供總結復盤。如有理解失當支持悉聽指教。
注：
(1) 文中的AMS皆指ActivityManager；
(2) LMK指LowMemoryKiller機制，其對應的進程名是lmkd；
(3) 所有Android源碼基于Android SDK 28（Android9/Android P），kernel層基于3.18版本。

1.1 LMK中kill進程的關鍵log（原生系統）：

LMK中kill進程的關鍵log

1.2 內核log信息（定制系統，原生系統看上面的截圖里的log）：

lowmemorykiller: Killing 'main' (1222) (tgid 1222), adj 100,\x0a   
to free 97596kB on behalf of 'kworker/u8:6' (3975) because\x0a   cache 19876kB is 
below limit 20480kB for oom_score_adj 100\x0a   defrag_free 3220kB\x0a  
 Free memory is -40312kB above reserved

二、粗略分析lowmemorykill.c中的實現邏輯

2.1 基本實現思路

  • Android的LMK機制是基于linux的OOM killer修改而來，具體實現是在驅動層，核心功能實現是在<font color=red>drivers/staging/android/lowmemorykiller.c</font>文件中，linux中的驅動實現都是以文件為載體的。
  • LowMemoryKiller會周期性的檢查當前系統的可用內存，當剩余可用內存較低時，便會觸發進程查殺策略，根據不同的可用內存的閾值來殺掉相應優先級的進程。
  • 關鍵字：LowMemoryKiller 可用內存閾值 進程優先級 oom_score_adj

2.2 是一定條件滿足時觸發or系統啟動就開始執行了？

2.3 核心邏輯

查看lowmemorykiller.c完整源碼
task_struct 定義在/include/linux/sched.h中：

2.3.1 定義一些“常量“：規則的量化標準
// 低內存時lowmem_adj分級
static short lowmem_adj[6] = {
    0,
    1,
    6,
    12,
};
// 共分了4個檔次
static int lowmem_adj_size = 4;
// 4個檔次下的可用內存預值
static int lowmem_minfree[6] = {
    3 * 512,    /* 6MB */
    2 * 1024,   /* 8MB */
    4 * 1024,   /* 16MB */
    16 * 1024,  /* 64MB */
};
static int lowmem_minfree_size = 4;
  • 疑問：lowmem_minfree數組中定義的內存閾值是這么算的？
2.3.2 遍歷進程->查殺流程：lowmem_scan()函數
   // lowmem_scan()函數掃描進程，對比系統剩余內存大小值，計算出當前屬于哪個閾值等級
78 // struct shrinker *s：
79 // struct shrink_control *sc: 
80 static unsigned long lowmem_scan(struct shrinker *s, struct shrink_control *sc)
81{
82  struct task_struct *tsk;
83  struct task_struct *selected = NULL;
84  unsigned long rem = 0;
85  int tasksize;
86  int i;
87  // score_adj的值越大優先級越低
87  short min_score_adj = OOM_SCORE_ADJ_MAX + 1;
88  int minfree = 0;
89  int selected_tasksize = 0;
90  short selected_oom_score_adj;
91  // lowmem_adj數組的size=4
91  int array_size = ARRAY_SIZE(lowmem_adj);
92  // other_free: 獲取剩余內存大小
92  int other_free = global_page_state(NR_FREE_PAGES) - totalreserve_pages;
93  // other_file
93  int other_file = global_page_state(NR_FILE_PAGES) -
94                      global_page_state(NR_SHMEM) -
95                      total_swapcache_pages();
96  // step1: 確認內存閾值分級數的size，目前看是4個等級；
97  if (lowmem_adj_size < array_size)
98      array_size = lowmem_adj_size; // 4
99  if (lowmem_minfree_size < array_size)
100     array_size = lowmem_minfree_size; // 4
101 // step2: 
    // 從6、8、16、64M中按從小到大逐個對比，找到當前系統剩余內存大小屬于哪個檔次
102 // 例如：當剩余內存低于64M時會得到min_score_adj = 12
101 for (i = 0; i < array_size; i++) {
102     minfree = lowmem_minfree[i];
103     if (other_free < minfree && other_file < minfree) {
104         min_score_adj = lowmem_adj[i];
105         break;
106     }
107 }
108 // 這里的log信息在分析進程被kill原因時也很關鍵！！
109 lowmem_print(3, "lowmem_scan %lu, %x, ofree %d %d, ma %hd\n",
110         sc->nr_to_scan, sc->gfp_mask, other_free,
111         other_file, min_score_adj);
112 // min_score_adj == OOM_SCORE_ADJ_MAX + 1代表未從內存閾值數組中找到等級
    // 說明剩余內存至少大于64M，當前系統剩余內存未達到需要kill某個進程的地步，
    // 所以直接return結束本次掃描
113 if (min_score_adj == OOM_SCORE_ADJ_MAX + 1) {
114     lowmem_print(5, "lowmem_scan %lu, %x, return 0\n",
115              sc->nr_to_scan, sc->gfp_mask);
116     return 0;
117 }
118 
119 selected_oom_score_adj = min_score_adj;
120
121 rcu_read_lock();
    // step3: 遍歷
122 for_each_process(tsk) {
123     struct task_struct *p;
124     short oom_score_adj;
125
126     if (tsk->flags & PF_KTHREAD)
127         continue;
128     // 代表進程的指針
129     p = find_lock_task_mm(tsk);
130     if (!p)
131         continue;
132
133     if (test_tsk_thread_flag(p, TIF_MEMDIE) &&
134         time_before_eq(jiffies, lowmem_deathpending_timeout)) {
135         task_unlock(p);
136         rcu_read_unlock();
137         return 0;
138     }
        // 從進程的結構體中讀取oom分數：oom_score_adj，這個值是否和上面定義的lowmem_adj屬于相同的取值范圍？？在哪里賦值的？？
139     oom_score_adj = p->signal->oom_score_adj;
        // 從進程中讀到的oom_score_adj < min_score_adj，
        // 說明p進程的優先級是高于當前低內存閾值對應的優先級的，不進行kill處理，跳過
140     if (oom_score_adj < min_score_adj) {
141         task_unlock(p);
142         continue;
143     }
        // 獲取這個p進程所占用的內存大小tasksize ，如果小于比我們當前選出進程的內存，
        // 則無視。如果大于則選中這個進程。
144     tasksize = get_mm_rss(p->mm);
145     task_unlock(p);
146     if (tasksize <= 0)
147         continue;
        // 首次走到這里時因為selected初始值為NULL，所以直接走else邏輯
148     if (selected) {
            // p進程的優先級是oom_score_adj，
            // 如果比當前內存閾值對應的oom_score_adj還小，
            // 代表p的優先級是高于當前的內存閾值等級的，也直接跳過
149         if (oom_score_adj < selected_oom_score_adj)
150             continue;
            // selected_tasksize初始值為0
            // oom_score_adj == selected_oom_score_adj代表當前進程p的oom_score_adj
            // 和內存閾值等級相等，也跳過，說明比較優先級時是不包含剛好優先級相等，而是要低于的
151         if (oom_score_adj == selected_oom_score_adj &&
152             tasksize <= selected_tasksize)
153             continue;
154     }
        // 優先級條件滿足，給selected變量賦值，用于后面對進程繼續操作
155     selected = p;
156     selected_tasksize = tasksize;
157     selected_oom_score_adj = oom_score_adj;
        // 這里的log信息也能用于分析當前滿足kill條件的進程是哪個！！
158     lowmem_print(2, "select '%s' (%d), adj %hd, size %d, to kill\n",
159              p->comm, p->pid, oom_score_adj, tasksize);
160     }
161 if (selected) {
        // PAGE_SIZE代表一個分頁的大小，等于4k
        // ！！到這里也能反過來推出other_file和min_free單位是頁，下面為了轉成KB單位，
        // 所以乘以了每個單頁的KB大小，比如：一個分頁是4KB，PAGE_SIZE / 1024 = 4，
        // 再用other_file * 4結果就是剩余內存有多少KB
162     long cache_size = other_file * (long)(PAGE_SIZE / 1024);
163     long cache_limit = minfree * (long)(PAGE_SIZE / 1024);
164     long free = other_free * (long)(PAGE_SIZE / 1024);
165     trace_lowmemory_kill(selected, cache_size, cache_limit, free);
        // ！！流程走到這里，下一步就是發送SIGKILL信號了，
        // 看到下面這條log就能確定進程即將被kill
166     lowmem_print(1, "Killing '%s' (%d), adj %hd,\n" \
167             "   to free %ldkB on behalf of '%s' (%d) because\n" \
168             "   cache %ldkB is below limit %ldkB for oom_score_adj %hd\n" \
169             "   Free memory is %ldkB above reserved\n",
170              selected->comm, selected->pid,
171              selected_oom_score_adj,
172              selected_tasksize * (long)(PAGE_SIZE / 1024),
173              current->comm, current->pid,
174              cache_size, cache_limit,
175              min_score_adj,
176              free);
177     lowmem_deathpending_timeout = jiffies + HZ;
178     set_tsk_thread_flag(selected, TIF_MEMDIE);
179     send_sig(SIGKILL, selected, 0);
180     rem += selected_tasksize;
181 }
182 // rem
183 lowmem_print(4, "lowmem_scan %lu, %x, return %lu\n",
184          sc->nr_to_scan, sc->gfp_mask, rem);
185 rcu_read_unlock();
186 return rem;
187}

經過 for_each 的遍歷， selected 就是我們選出要釋放掉的bad進程，它具有下面兩個條件：
第一、Oom_adj大于當前警戒閾值并且最大；
第二、在同樣大小的oom_adj中，占用內存最多。

  • 總結以上的查殺流程如下圖：


    lmk機制的查殺流程

三、幾個疑問的思考

3.1 為什么在計算剩余可用內存時，有other_free和other_file兩個數值？

單位都是頁數
定義：

92  // other_free: 獲取剩余內存大小
92  int other_free = global_page_state(NR_FREE_PAGES) - totalreserve_pages;
93  // other_file
93  int other_file = global_page_state(NR_FILE_PAGES) -
94                      global_page_state(NR_SHMEM) -
95                      total_swapcache_pages();

3.2 lowmem_adj數組中定義的oom_scrore_adj和task_struct->signal->oom_score_adj的值即然能比較，那進程中的oom_score_adj是在哪里賦值的？？

存儲在/proc/pid/oom_score_adj文件中。
比如查看init進程的oom_score_adj文件：


查看init進程的oom_score_adj值

3.3 內核中kill掉了應用進程，那怎么通知被殺進程做后續的進程數據清理操作？如何通知過去的？

????AMS中有一個bindApplication方法，內部會在Application執行attachApplication()時，綁定IApplicationThread的實現類的邏輯，會有binder斷開的監聽邏輯。

3.3.1 com.android.server.am.ActivityManagerService#attachApplication()
@Override
public final void attachApplication(IApplicationThread thread, long startSeq) {
    synchronized (this) {
        int callingPid = Binder.getCallingPid();
        final int callingUid = Binder.getCallingUid();
        final long origId = Binder.clearCallingIdentity();
        // 繼續看該方法實現-> 3.3.2
        attachApplicationLocked(thread, callingPid, callingUid, startSeq);
        Binder.restoreCallingIdentity(origId);
   }
}
3.3.2 com.android.server.am.ActivityManagerService#attachApplicationLocked()
private final boolean attachApplicationLocked(IApplicationThread thread,
            int pid, int callingUid, long startSeq) {
        // ...
        // If this application record is still attached to a previous
        // process, clean it up now.
        if (app.thread != null) {
            handleAppDiedLocked(app, true, true);
        }
       // ...
       // IBinder.DeathRecipient的實現類是AMS$AppDeathRecipient->3.3.3
       AppDeathRecipient adr = new AppDeathRecipient(app, pid, thread);
       // 這里的代碼寫法跟我們Context.bindService()，傳入的ServiceConnect回調中拿到了遠程進程的IBinder對象，
       // 然后為了監聽服務端進程死亡后執行相應的處理邏輯（重試或直接停止邏輯），是一樣的用法。                      
       thread.asBinder().linkToDeath(adr, 0);            
       app.deathRecipient = adr;                    
       // ...     
}
3.3.3 com.android.server.am.ActivityManagerService.AppDeathRecipient
@Override
public void binderDied() {
    synchronized(ActivityManagerService.this) {
       appDiedLocked(mApp, mPid, mAppThread, true, null);
    }
}

????注意這時候的CS模型中，應用程序（ActivityThread$IApplicationThread）是服務端（binder接口的實現方），而運行在system_server進程的AMS是客戶端。AMS在bindApplication時，傳入了IApplicationThread引用，然后每當需要AMS和應用進程通信時，都是通過IApplicationThread對象轉調到應用進程。

  • LowMemoryKiller殺死應用后可能在應用的日志文件查詢不到“ActivityManager : Killing”相關log，必要時需要查看內核層的log。
最后編輯于 ：
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明：文章內容（如有圖片或視頻亦包括在內）由作者上傳并發布，文章內容僅代表作者本人觀點，簡書系信息發布平臺，僅提供信息存儲服務。