You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Based on the current LMK implementation, LMK has to scan all processes to
select the correct task to kill during low memory.
The basic idea for the optimization is to :
queue all tasks with oom_score_adj priority, and then LMK just selects the
proper task from the queue(rbtree) to kill.
performance improvement:
the current implementation: average time to find a task to kill : 1004us
the optimized implementation: average time to find a task to kill: 43us
squished another 3 commits:
staging: android: lowmemorykiller: select a new task to kill
Under certain circumstances, a process may take time to handle a SIGKILL.
When lowmemkiller is called again shortly after, it would pick the same
process to kill over and over, so that we cann't get free memory for long time.
Solution is to check fatal_signal_pending() on the selected task, and if it's
already pending, select a new task to kill.
staging: android: lmk: skip if killed by lmk
A task can be selected to kill when it's already exiting. Sending
signal to the task at that state won't set TIF_SIGPENDING for it.
After that, every task including threads in the exiting task itself
running into lmk will compete for the mutex, then spend some time
waiting for the exiting task to release memory or try to send signal
to the same task again.
We want the exiting task to exit as early as possible but it's slowed
down greatly by the mutex and waiting. Skip lmk if current thread
group leader is exiting and is killed by lmk. Also delegate TIF_MEMDIE
to current task.
staging: android: lmk: check TIF directly
When trying to fix that lmk can't kill an exiting task
(commit 895304e
(CR) staging: android: lmk: skip if killed by lmk),
additional check was added for the TIF_MEMDIE flag.
However the task lock has already been taken when examining
the task. The same helper function which tries to grab the
task lock again will be deadlocked.
Change to check the thread flag of thread group leader directly.
Change-Id: Ibbb99cbd36e27a546195b4d4bed59b3829e6b7b0
0 commit comments