Android lowmemorykiller分析
1.概述
Android底層仍是基於Linux，在Linux中低內存是會有oom killer去殺掉一些進程去釋放內存，而Android中的lowmemorykiller就是在此基礎上作了一些調整來的。由於手機上的內存畢竟比較有限，而Android中APP在不使用以後並非立刻被殺掉，雖然上層ActivityManagerService中也有不少關於進程的調度以及殺進程的手段，可是畢竟還須要考慮手機剩餘內存的實際狀況，linux
lowmemorykiller的做用就是當內存比較緊張的時候去及時殺掉一些ActivityManagerService還沒來得及殺掉可是對用戶來講不那麼重要的進程，回收一些內存，保證手機的正常運行。android
lowmemkiller中會涉及到幾個重要的概念：ios
/sys/module/lowmemorykiller/parameters/minfree：裏面是以」,」分割的一組數，每一個數字表明一個內存級別算法
/sys/module/lowmemorykiller/parameters/adj：對應上面的一組數，每一個數組表明一個進程優先級級別數組
舉個例子：數據結構
/sys/module/lowmemorykiller/parameters/minfree：18432,23040,27648,32256,55296,80640socket
/sys/module/lowmemorykiller/parameters/adj：0,100,200,300,900,906函數
表明的意思：兩組數一一對應，當手機內存低於80640時，就去殺掉優先級906以及以上級別的進程，當內存低於55296時，就去殺掉優先級900以及以上的進程。oop
對每一個進程來講：ui
/proc/pid/oom_adj：表明當前進程的優先級，這個優先級是kernel中的優先級，這個優先級與上層的優先級之間有一個換算，文章最後會提一下。
/proc/pid/oom_score_adj：上層優先級，跟ProcessList中的優先級對應
2.init進程lmkd
代碼位置:platform/system/core/lmkd/
ProcessList中定義有進程的優先級，越重要的進程的優先級越低，前臺APP的優先級爲0，系統APP的優先級通常都是負值，因此通常進程管理以及殺進程都是針對與上層的APP來講的，而這些進程的優先級調整都在AMS裏面，AMS根據進程中的組件的狀態去不斷的計算每一個進程的優先級，計算以後，會及時更新到對應進程的文件節點中，而這個對文件節點的更新並非它完成的，而是lmkd，他們之間經過socket通訊。
lmkd在手機中是一個常駐進程，用來處理上層ActivityManager在進行updateOomAdj以後，經過socket與lmkd進行通訊，更新進程的優先級，若是必要則殺掉進程釋放內存。lmkd是在init進程啓動的時候啓動的，在lmkd中有定義lmkd.rc:
service lmkd /system/bin/lmkd
class core
group root readproc
critical
socket lmkd seqpacket 0660 system system
writepid /dev/cpuset/system-background/tasks
上層AMS跟lmkd通訊主要分爲三種command，每種command表明一種數據控制方式，在ProcessList以及lmkd中都有定義：
LMK_TARGET：更新/sys/module/lowmemorykiller/parameters/中的minfree以及adj LMK_PROCPRIO：更新指定進程的優先級，也就是oom_score_adj LMK_PROCREMOVE：移除進程
在開始介紹lmkd的處理邏輯以前，lmkd.c中有幾個重要的變量與數據結構提早說明一下：
// 內存級別限額
#define INKERNEL_MINFREE_PATH "/sys/module/lowmemorykiller/parameters/minfree"
// 不一樣級別內存對應要殺的的優先級
#define INKERNEL_ADJ_PATH "/sys/module/lowmemorykiller/parameters/adj"
// 裝載上面兩組數字的數組
static int lowmem_adj[MAX_TARGETS];
static int lowmem_minfree[MAX_TARGETS];
// 三種command
enum lmk_cmd {
LMK_TARGET,
LMK_PROCPRIO,
LMK_PROCREMOVE,
};
// 優先級的最小值
#define OOM_SCORE_ADJ_MIN (-1000)
// 優先級最大值
#define OOM_SCORE_ADJ_MAX 1000
// 雙向鏈表結構體
struct adjslot_list {
struct adjslot_list *next;
struct adjslot_list *prev;
};
// 進程在lmkd中的數據結構體
struct proc {
struct adjslot_list asl;
int pid;
uid_t uid;
int oomadj;
struct proc *pidhash_next;
};
// 存放進程proc的hashtable，index是經過pid的計算得出
static struct proc *pidhash[PIDHASH_SZ];
// 根據pid計算index的hash算法
#define pid_hashfn(x) ((((x) >> 8) ^ (x)) & (PIDHASH_SZ - 1))
// 進程優先級到數組的index之間的轉換
// 由於進程的優先級能夠是負值，可是數組的index不能爲負值
// 不過由於這個轉換隻是簡單加了1000，爲了方便，後面的描述中就認爲是優先級直接作了index
#define ADJTOSLOT(adj) (adj + -OOM_SCORE_ADJ_MIN)
// table，相似hashtable，不過計算index的方式不是hash，而是oom_score_adj通過轉換後直接做爲index
// 數組的每一個元素都是雙向循環鏈表
// 進程的優先級做爲數組的index
// 即以進程的優先級爲index，從-1000到+1000 + 1大小的數組，根據優先級，同優先級的進程index相同
// 每一個元素是一個雙向鏈表，這個鏈表上的全部proc的優先級都相同
// 這樣根據優先級殺進程的時候就會很是方便，要殺指定優先級的進程能夠根據優先級獲取到一個進程鏈表，逐個去殺。
static struct adjslot_list procadjslot_list[ADJTOSLOT(OOM_SCORE_ADJ_MAX) + 1];
2.1 lmkd進程啓動入口
int main(int argc __unused, char **argv __unused) {
struct sched_param param = {
.sched_priority = 1,
};
// 將此進程將來使用到的全部內存都鎖在物理內存中，防止內存被交換
mlockall(MCL_FUTURE);
// 設置此線程的調度策略爲SCHED_FIFO，first-in-first-out，param中主要設置sched_priority
// 因爲SCHED_FIFO是一種實時調度策略，在這個策略下優先級從1(low) -> 99(high)
// 實時線程一般會比普通線程有更高的優先級
sched_setscheduler(0, SCHED_FIFO, ¶m);
// 初始化epoll以及與ActivityManager的socket鏈接,等待cmd和data
if (!init())
// 進入死循環epoll_wait等待fd事件
mainloop();
ALOGI("exiting");
return 0;
}
前面已經提到，這個進程存在的主要做用是跟AMS進行通訊，更新oomAdj，在必要的時候殺掉進程。因此在main函數中主要就是建立了epoll以及初始化socket並鏈接ActivityManager，而後阻塞等待上層傳遞cmd以及數據過來。
2.2 init初始化
static int init(void) {
...
// 拿到lmkd的socket fd
ctrl_lfd = android_get_control_socket("lmkd");
if (ctrl_lfd < 0) {
ALOGE("get lmkd control socket failed");
return -1;
}
// server listen
ret = listen(ctrl_lfd, 1);
if (ret < 0) {
ALOGE("lmkd control socket listen failed (errno=%d)", errno);
return -1;
}
epev.events = EPOLLIN;
// ctrl_connect_handler裏面完成了soclet的accpet以及read數據，並對數據進行相應的處理
epev.data.ptr = (void *)ctrl_connect_handler;
if (epoll_ctl(epollfd, EPOLL_CTL_ADD, ctrl_lfd, &epev) == -1) {
ALOGE("epoll_ctl for lmkd control socket failed (errno=%d)", errno);
return -1;
}
maxevents++;
// 使用kernel空間的處理
use_inkernel_interface = !access(INKERNEL_MINFREE_PATH, W_OK);
if (use_inkernel_interface) {
ALOGI("Using in-kernel low memory killer interface");
} else {
ret = init_mp(MEMPRESSURE_WATCH_LEVEL, (void *)&mp_event);
if (ret)
ALOGE("Kernel does not support memory pressure events or in-kernel low memory killer");
}
// 雙向鏈表初始化
for (i = 0; i <= ADJTOSLOT(OOM_SCORE_ADJ_MAX); i++) {
procadjslot_list[i].next = &procadjslot_list[i];
procadjslot_list[i].prev = &procadjslot_list[i];
}
return 0;
}
在初始化的時候，有一個很重要的判斷：use_inkernel_interface，這個是根據是否有/sys/module/lowmemorykiller/parameters/minfree的寫權限來判斷的，沒有的狀況下就使用kernel空間的邏輯
目前遇到的都是use_inkernel_interface
若是use_inkernel_interface的值爲false：
2.3 進入loop循環mainloop
// 進入死循環，而後調用epoll_wait阻塞等待事件的到來
static void mainloop(void) {
while (1) {
struct epoll_event events[maxevents];
int nevents;
int i;
ctrl_dfd_reopened = 0;
nevents = epoll_wait(epollfd, events, maxevents, -1);
if (nevents == -1) {
if (errno == EINTR)
continue;
ALOGE("epoll_wait failed (errno=%d)", errno);
continue;
}
for (i = 0; i < nevents; ++i) {
if (events[i].events & EPOLLERR)
ALOGD("EPOLLERR on event #%d", i);
if (events[i].data.ptr)
(*(void (*)(uint32_t))events[i].data.ptr)(events[i].events);
}
}
}
2.4 處理socket傳遞過來的數據ctrl_command_handler
前面在ctrl_connect_handler這個方法中處理了accept，並開始了ctrl_data_handler中讀取數據並進行處理：ctrl_command_handler。對於ActivityManager傳遞來的Command以及data的主要處理邏輯就在ctrl_command_handler中。
static void ctrl_command_handler(void) {
int ibuf[CTRL_PACKET_MAX / sizeof(int)];
int len;
int cmd = -1;
int nargs;
int targets;
len = ctrl_data_read((char *)ibuf, CTRL_PACKET_MAX);
if (len <= 0)
return;
nargs = len / sizeof(int) - 1;
if (nargs < 0)
goto wronglen;
cmd = ntohl(ibuf[0]);
// 一共三種command，在前面靜態變量的定義處已經介紹過
switch(cmd) {
// 更新內存級別以及對應級別的進程adj
case LMK_TARGET:
targets = nargs / 2;
if (nargs & 0x1 || targets > (int)ARRAY_SIZE(lowmem_adj))
goto wronglen;
cmd_target(targets, &ibuf[1]);
break;
// 根據pid更新adj
case LMK_PROCPRIO:
if (nargs != 3)
goto wronglen;
cmd_procprio(ntohl(ibuf[1]), ntohl(ibuf[2]), ntohl(ibuf[3]));
break;
// 根據pid移除proc
case LMK_PROCREMOVE:
if (nargs != 1)
goto wronglen;
cmd_procremove(ntohl(ibuf[1]));
break;
default:
ALOGE("Received unknown command code %d", cmd);
return;
}
return;
wronglen:
ALOGE("Wrong control socket read length cmd=%d len=%d", cmd, len);
}
上層代碼的調用時機這裏就不細化了，往前追的話基本都是在ActivityManagerService中的udpateOomAdj中，也就是說上層根據四大組件的狀態對進程的優先級進行調整以後，會及時的反應到lmkd中，在內存不足的時候觸發殺進程，會從低優先級開始殺進程。command一共有三種，在上層的代碼是在ProcessList中。
2.4.1 LMK_TARGET
// 上層邏輯是在ProcessList.updateOomLevels中
ByteBuffer buf = ByteBuffer.allocate(4 * (2*mOomAdj.length + 1));
buf.putInt(LMK_TARGET);
for (int i=0; i<mOomAdj.length; i++) {
buf.putInt((mOomMinFree[i]*1024)/PAGE_SIZE);
buf.putInt(mOomAdj[i]);
}
writeLmkd(buf)
// lmkd處理邏輯
static void cmd_target(int ntargets, int *params) {
int i;
if (ntargets > (int)ARRAY_SIZE(lowmem_adj))
return;
// 這個for循環對應上面的for循環，將數據讀出裝進數組中
for (i = 0; i < ntargets; i++) {
lowmem_minfree[i] = ntohl(*params++);
lowmem_adj[i] = ntohl(*params++);
}
lowmem_targets_size = ntargets;
// 使用kernel空間的處理邏輯
if (use_inkernel_interface) {
char minfreestr[128];
char killpriostr[128];
minfreestr[0] = '\0';
killpriostr[0] = '\0';
// 取出兩個數組中的數據，以","分隔，分別拼接成string
for (i = 0; i < lowmem_targets_size; i++) {
char val[40];
if (i) {
strlcat(minfreestr, ",", sizeof(minfreestr));
strlcat(killpriostr, ",", sizeof(killpriostr));
}
snprintf(val, sizeof(val), "%d", lowmem_minfree[i]);
strlcat(minfreestr, val, sizeof(minfreestr));
snprintf(val, sizeof(val), "%d", lowmem_adj[i]);
strlcat(killpriostr, val, sizeof(killpriostr));
}
// 將生成好的string寫入到文件節點minfree以及adj
writefilestring(INKERNEL_MINFREE_PATH, minfreestr);
writefilestring(INKERNEL_ADJ_PATH, killpriostr);
}
}
上面的處理邏輯主要是：
- 按照順序取出數據，裝進lmkd的數組中。
- 分別將兩個數組中的數取出，用」,」分隔
- lowmem_minfree中的數據拼成的string寫到 「/sys/module/lowmemorykiller/parameters/minfree」
- lowmem_adj中的數據拼成的string寫到 「/sys/module/lowmemorykiller/parameters/adj」
2.4.2 LMK_PROCPRIO
// 上層邏輯是在ProcessList.setOomAdj中
public static final void setOomAdj(int pid, int uid, int amt) {
if (amt == UNKNOWN_ADJ)
return;
long start = SystemClock.elapsedRealtime();
ByteBuffer buf = ByteBuffer.allocate(4 * 4);
buf.putInt(LMK_PROCPRIO);
buf.putInt(pid);
buf.putInt(uid);
buf.putInt(amt);
writeLmkd(buf);
long now = SystemClock.elapsedRealtime();
if ((now-start) > 250) {
Slog.w("ActivityManager", "SLOW OOM ADJ: " + (now-start) + "ms for pid " + pid
+ " = " + amt);
}
}
// lmkd處理邏輯
static void cmd_procprio(int pid, int uid, int oomadj) {
struct proc *procp;
char path[80];
char val[20];
if (oomadj < OOM_SCORE_ADJ_MIN || oomadj > OOM_SCORE_ADJ_MAX) {
ALOGE("Invalid PROCPRIO oomadj argument %d", oomadj);
return;
}
// LMK_PROCPRIO的主要做用就是更新進程的oomAdj
// 將上層傳遞過來的數據（pid以及優先級）寫到該進程對應的文件節點
// /proc/pid/oom_score_adj
snprintf(path, sizeof(path), "/proc/%d/oom_score_adj", pid);
snprintf(val, sizeof(val), "%d", oomadj);
writefilestring(path, val);
// 若是使用kernel的使用邏輯，return
// 即這個command傳遞過來只是更新了對應文件節點的oom_score_adj
if (use_inkernel_interface)
return;
// 從hashtable中查找proc
procp = pid_lookup(pid);
// 若是沒有查找到，也就是說這個進程是新建立的，lmkd維護的數據結構中尚未這個proc，所以須要新建並添加到hashtable中
if (!procp) {
procp = malloc(sizeof(struct proc));
if (!procp) {
// Oh, the irony. May need to rebuild our state.
return;
}
procp->pid = pid;
procp->uid = uid;
procp->oomadj = oomadj;
// 將proc插入到lmkd中的數據結構中，主要包括兩個數據結構
// 更新hashtable，經過pid計算hash值，而後存儲，解決衝突是讓新來的做爲數組元素鏈表的頭結點
// 優先級爲index的雙向鏈表組成的table
proc_insert(procp);
} else {
// hashtable中已經有這個proc
// 可是由於優先級的變化，須要先把這個proc從原先的優先級table中對應位置的雙向鏈表中remove
// 而後新加到新的優先級對應的雙向鏈表中
// 雙向鏈表的添加是新來的放在頭部
proc_unslot(procp);
procp->oomadj = oomadj;
proc_slot(procp);
}
}
// 其中pid_lookup：查詢hashtable，由於進程的pid是惟一的，而後從中取出該pid在lmkd中的proc結構體。
static struct proc *pid_lookup(int pid) {
struct proc *procp;
for (procp = pidhash[pid_hashfn(pid)]; procp && procp->pid != pid;
procp = procp->pidhash_next)
;
return procp;
}
2.4.3 LMK_PROCREMOVE
// 上層處理邏輯在ProcessList.remove中
public static final void remove(int pid) {
ByteBuffer buf = ByteBuffer.allocate(4 * 2);
buf.putInt(LMK_PROCREMOVE);
buf.putInt(pid);
writeLmkd(buf);
}
// lmkd處理邏輯
static void cmd_procremove(int pid) {
// 若是使用kernel接口,return
if (use_inkernel_interface)
return;
// 更新數據結構，pid的hashtable以及進程優先級的雙向鏈表table
pid_remove(pid);
kill_lasttime = 0;
}
static int pid_remove(int pid) {
int hval = pid_hashfn(pid);
struct proc *procp;
struct proc *prevp;
// pid的hashtable
for (procp = pidhash[hval], prevp = NULL; procp && procp->pid != pid;
procp = procp->pidhash_next)
prevp = procp;
if (!procp)
return -1;
if (!prevp)
pidhash[hval] = procp->pidhash_next;
else
prevp->pidhash_next = procp->pidhash_next;
// 進程優先級的table
proc_unslot(procp);
free(procp);
return 0;
}
2.4.4 小結
從上面的處理邏輯就能看出來，三種command的處理邏輯中都對use_inkernel_interface的狀況下作了特殊處理，在use_inkernel_interface的狀況下，作的事情都是很簡單的，只是更新一下文件節點。若是不使用kernel interface，就須要lmkd本身維護兩個table，在每次更新adj的時候去更新table。 且在初始化的時候也能看到，若是不使用kernel的lowmemorykiller，則須要lmkd本身獲取手機內存狀態，若是匹配到了minfree中的等級，則須要經過殺掉一些進程釋放內存。
2.5 殺進程
初始化的時候已經註冊好了，當獲取到手機的內存匹配到minfree中某一個級別時：
2.5.1 查找
// 不使用kernel interface
// 根據當前內存的狀態查找須要殺掉的進程
static int find_and_kill_process(int other_free, int other_file, bool first)
{
...
// 主要邏輯是這裏的for循環
// 根據前面最小內存級別與優先級的對應關係
// 拿到須要殺的進程的優先級
for (i = 0; i < lowmem_targets_size; i++) {
minfree = lowmem_minfree[i];
if (other_free < minfree && other_file < minfree) {
min_score_adj = lowmem_adj[i];
break;
}
}
if (min_score_adj == OOM_SCORE_ADJ_MAX + 1)
return 0;
for (i = OOM_SCORE_ADJ_MAX; i >= min_score_adj; i--) {
struct proc *procp;
retry:
// 從優先級table中取出一個
// 由於是雙向循環鏈表，取的時候取出head->prev，也就是最後一個
// 也就是使用的lru算法，先把近期不用的進程殺掉
procp = proc_adj_lru(i);
if (procp) {
// 殺進程，經過發信號的方式
// 返回值是殺了該進程以後釋放的內存的大小
// 若是釋放內存以後依然不知足要求，則從鏈表上再取一個殺
killed_size = kill_one_process(procp, other_free, other_file, minfree, min_score_adj, first);
if (killed_size < 0) {
goto retry;
} else {
return killed_size;
}
}
}
return 0;
}
2.6 小結
這部分從lmkd的main開始，從一些數據結構的初始化，到進入loop，再到與ActivityManager的socket鏈接，接收上層傳遞的數據，而後分別根據三種command作出不一樣的更新與刪除等。固然最重要的仍是use_inkernel_interface這個變量，從初始化到全部命令的處理都與這個邏輯分不開，若是不使用的話，須要自維護進程的數據結構，須要讀取文件節點獲取手機內存狀態，在minfree匹配到時去查找並殺進程，直到釋放足夠多的內存。在使用kernel空間lowmemorykiller的狀況下，三種命令作的事情會很是有限，主要是更新文件節點，而lmdk自己根本不須要維護任何跟進程相關的結構，判斷手機狀態並查找低優先級的進程以及殺進程的工做所有都由lowmemorykiller完成。
3. lowmemorykiller
前面也提過，大多狀況實際上是使用kernel interface的，其實也就是kernel中的lowmemorykiller
代碼位置:/kernel/msm-3.18/drivers/staging/android/lowmemorykiller.c
lowmemorykiller中是經過linux的shrinker實現的，這個是linux的內存回收機制的一種，由內核線程kswapd負責監控，在lowmemorykiller初始化的時候註冊register_shrinker。
static int __init lowmem_init(void)
{
register_shrinker(&lowmem_shrinker);
vmpressure_notifier_register(&lmk_vmpr_nb);
return 0;
}
minfree以及min_adj兩個數組：
// 下面兩個數組分別表明了兩個參數文件中的默認值，數組默認的size都是6
// 對應 "/sys/module/lowmemorykiller/parameters/adj"
static short lowmem_adj[6] = {
0,
1,
6,
12,
};
static int lowmem_adj_size = 4;
// 對應 "/sys/module/lowmemorykiller/parameters/minfree"
static int lowmem_minfree[6] = {
3 * 512, /* 6MB */
2 * 1024, /* 8MB */
4 * 1024, /* 16MB */
16 * 1024, /* 64MB */
};
static int lowmem_minfree_size = 4;
掃描當前內存以及殺進程：
static unsigned long lowmem_scan(struct shrinker *s, struct shrink_control *sc)
{
struct task_struct *tsk;
struct task_struct *selected = NULL;
unsigned long rem = 0;
int tasksize;
int i;
// OOM_SCORE_ADJ_MAX = 1000
short min_score_adj = OOM_SCORE_ADJ_MAX + 1;
int minfree = 0;
int selected_tasksize = 0;
short selected_oom_score_adj;
// array_size = 6
int array_size = ARRAY_SIZE(lowmem_adj);
// NR_FREE_PAGES 是在/kernel/msm-3.18/include/linux/mmzone.h中定義的zone_stat_item對應的第一個枚舉，下面的枚舉以此類推
// global_page_state(NR_FREE_PAGES)即讀取/proc/vmstat 中第一行的值
int other_free = global_page_state(NR_FREE_PAGES) - totalreserve_pages;
int other_file = global_page_state(NR_FILE_PAGES) -
global_page_state(NR_SHMEM) -
global_page_state(NR_UNEVICTABLE) -
total_swapcache_pages();
if (lowmem_adj_size < array_size)
array_size = lowmem_adj_size;
if (lowmem_minfree_size < array_size)
array_size = lowmem_minfree_size;
for (i = 0; i < array_size; i++) {
// 從小到大掃描lowmem_minfree數組，根據剩餘內存的大小，肯定當前剩餘內存的級別
minfree = lowmem_minfree[i];
if (other_free < minfree && other_file < (minfree + minfree / 4)) {
// 因爲兩個數組之間的對應關係，minfree中找到當前內存所處的等級以後
// 也就能夠在lowmem_adj獲取到在這個內存級別須要殺掉的進程的優先級
min_score_adj = lowmem_adj[i];
break;
}
}
lowmem_print(3, "lowmem_scan %lu, %x, ofree %d %d, ma %hd\n",
sc->nr_to_scan, sc->gfp_mask, other_free,
other_file, min_score_adj);
// 通過一輪掃描，發現不須要殺進程，return
if (min_score_adj == OOM_SCORE_ADJ_MAX + 1) {
lowmem_print(5, "lowmem_scan %lu, %x, return 0\n",
sc->nr_to_scan, sc->gfp_mask);
return 0;
}
selected_oom_score_adj = min_score_adj;
// 內核一種同步機制 -- RCU同步機制
rcu_read_lock();
again:
// for_each_process用來遍歷全部的進程
// 定義在 /kernel/msm-3.18/include/linux/sched.h
// #define for_each_process(p) \
// for (p = &init_task ; (p = next_task(p)) != &init_task ; )
for_each_process(tsk) {
struct task_struct *p;
short oom_score_adj;
// 內核線程kthread
if (tsk->flags & PF_KTHREAD)
continue;
// 已經被殺，還在等鎖
if (test_tsk_lmk_waiting(tsk)) {
lowmem_print(2, "%s (%d) is already killed, skip\n",
tsk->comm, tsk->pid);
continue;
}
// 一個task
// 定義在 /kernel/msm-3.18/mm/oom_kill.c
p = find_lock_task_mm(tsk);
if (!p)
continue;
oom_score_adj = p->signal->oom_score_adj;
if (oom_score_adj < min_score_adj) {
// 若是當前找到的進程的oom_score_adj比當前須要殺的最小優先級還低，不殺
task_unlock(p);
continue;
}
// 拿到佔用的內存大小
// 定義在 /kernel/msm-3.18/include/linux/mm.h
tasksize = get_mm_rss(p->mm);
#ifdef CONFIG_ZRAM
tasksize += (get_mm_counter(p->mm, MM_SWAPENTS) / 3);
#endif
task_unlock(p);
if (tasksize <= 0)
continue;
if (selected) {
// 第一次不會進到這
// 第二次，也就是循環回來，判斷若是當前選中的進程的adj更小
// 或優先級相同可是內存比較小，則continue
if (oom_score_adj < selected_oom_score_adj)
continue;
if (oom_score_adj == selected_oom_score_adj &&
tasksize <= selected_tasksize)
continue;
}
selected = p;
selected_tasksize = tasksize;
selected_oom_score_adj = oom_score_adj;
// 已經選中了進程p，準備kill
lowmem_print(2, "select '%s' (%d, %d), adj %hd, size %d, to kill\n",
p->comm, p->pid, p->tgid, oom_score_adj, tasksize);
}
if (selected) {
task_lock(selected);
// 給該進程發信號 SIGKILL
send_sig(SIGKILL, selected, 0);
if (selected->mm)
task_set_lmk_waiting(selected);
task_unlock(selected);
// 殺進程完畢，打印kernel log, tag是lowmemorykiller
lowmem_print(1, "Killing '%s' (%d), adj %hd,\n"
" to free %ldkB on behalf of '%s' (%d) because\n"
" cache %ldkB is below limit %ldkB for oom_score_adj %hd\n"
" Free memory is %ldkB above reserved\n",
selected->comm, selected->pid,
selected_oom_score_adj,
selected_tasksize * (long)(PAGE_SIZE / 1024),
current->comm, current->pid,
other_file * (long)(PAGE_SIZE / 1024),
minfree * (long)(PAGE_SIZE / 1024),
min_score_adj,
other_free * (long)(PAGE_SIZE / 1024));
lowmem_deathpending_timeout = jiffies + HZ;
// 釋放的內存大小
rem += selected_tasksize;
}
// 若是須要殺掉多個進程
// kill_one_more在lmk_vmpressure_notifier中置true
if (kill_one_more) {
selected = NULL;
kill_one_more = false;
lowmem_print(1, "lowmem_scan kill one more process\n");
// 跳轉到遍歷的地方再開始
goto again;
}
lowmem_print(4, "lowmem_scan %lu, %x, return %lu\n",
sc->nr_to_scan, sc->gfp_mask, rem);
rcu_read_unlock();
return rem;
}
lmk_vmpressure_notifier中定義了何時去kill_one_more，主要是當內存壓力在95以上時
lmk_vmpressure_notifier這個也是在init時註冊：vmpressure_notifier_register(&lmk_vmpr_nb);
static int lmk_vmpressure_notifier(struct notifier_block *nb,
unsigned long action, void *data)
{
unsigned long pressure = action;
if (pressure >= 95) {
if (!kill_one_more) {
kill_one_more = true;
lowmem_print(2, "vmpressure %ld, set kill_one_more true\n",
pressure);
}
} else {
if (kill_one_more) {
kill_one_more = false;
lowmem_print(2, "vmpressure %ld, set kill_one_more false\n",
pressure);
}
}
return 0;
}
oom_adj到oom_score_adj的轉換：
static short lowmem_oom_adj_to_oom_score_adj(short oom_adj)
{
if (oom_adj == OOM_ADJUST_MAX)
return OOM_SCORE_ADJ_MAX;
else
return (oom_adj * OOM_SCORE_ADJ_MAX) / -OOM_DISABLE;
}
4. 總結
因爲Android中的進程啓動的很頻繁，四大組件都會涉及到進程啓動，進程啓動以後作完組要作的事情以後就會很快被AMS把優先級下降，可是爲了針對低內存的狀況以及若是用戶開啓太多，且APP的優先級很高，AMS這邊就有一些無力了，爲了保證手機正常運行必須有進程清理，內存回收，根據當前手機剩餘內存的狀態，在minfree中找到當前等級，再根據這個等級去adj中找到這個等級應該殺掉的進程的優先級，而後去殺進程，直到釋放足夠的內存。目前大多都使用kernel中的lowmemorykiller，可是上層用戶的APP的優先級的調整仍是AMS來完成的，lmkd在中間充當了一個橋樑的角色，經過把上層的更新以後的adj寫入到文件節點，提供lowmemorykiller殺進程的依據。
相關文章
- 1. 內存泄露Lowmemorykiller分析
- 2. Android LowMemoryKiller 簡介
- 3. Android LowMemoryKiller 初識
- 4. LowMemoryKiller機制簡析
- 5. Android進程系列第六篇---LowmemoryKiller機制分析(上)
- 6. Android 6.0的lowmemorykiller機制
- 7. 【性能】OOM原理解析：LowMemoryKiller原理
- 8. Android後臺殺死系列之三：LowMemoryKiller原理（4.3-6.0）
- 9. 【Android 系統開發】_「核心技術」篇 -- LowMemoryKiller
- 10. Android kswapd-->lowmemorykiller啓動和掃描過程
- 更多相關文章...
- • Kotlin Android 環境搭建 - Kotlin 教程
- • 互聯網系統應用架構基礎分析 - 紅包項目實戰
- • Git五分鐘教程
- • 算法總結-二分查找法
相關標籤/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
最新文章
- 1. 升級Gradle後報錯Gradle‘s dependency cache may be corrupt (this sometimes occurs
- 2. Smarter, Not Harder
- 3. mac-2019-react-native 本地環境搭建(xcode-11.1和android studio3.5.2中Genymotion2.12.1 和VirtualBox-5.2.34 )
- 4. 查看文件中關鍵字前後幾行的內容
- 5. XXE萌新進階全攻略
- 6. Installation failed due to: ‘Connection refused: connect‘安卓studio端口占用
- 7. zabbix5.0通過agent監控winserve12
- 8. IT行業UI前景、潛力如何？
- 9. Mac Swig 3.0.12 安裝
- 10. Windows上FreeRDP-WebConnect是一個開源HTML5代理，它提供對使用RDP的任何Windows服務器和工作站的Web訪問
歡迎關注本站公眾號,獲取更多信息
相關文章
- 1. 內存泄露Lowmemorykiller分析
- 2. Android LowMemoryKiller 簡介
- 3. Android LowMemoryKiller 初識
- 4. LowMemoryKiller機制簡析
- 5. Android進程系列第六篇---LowmemoryKiller機制分析(上)
- 6. Android 6.0的lowmemorykiller機制
- 7. 【性能】OOM原理解析：LowMemoryKiller原理
- 8. Android後臺殺死系列之三：LowMemoryKiller原理（4.3-6.0）
- 9. 【Android 系統開發】_「核心技術」篇 -- LowMemoryKiller
- 10. Android kswapd-->lowmemorykiller啓動和掃描過程