Not boosting kill target's priority can cause priority inversion. Boost
its priority from the reaper thread right after sending a SIGKILL to
prevent priority inversion. Also, using normal priority to the victim
processes. Thus, they won't take too much CPU resource which preempt
UI or important processes.
Bug: 238495258
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I789ec402f038a1b48d25f62f859be69bbddfad16
lmkd main thread is running at RT priority to prevent it from being
blocked by other processes. However when all reaper threads are busy,
lmkd will kill and reap the memory of the target process from the
context of the main thread and that can cause two issues:
1. lmkd main thread gets blocked for considerable duration.
2. lmkd main and reaper threads might monopolize CPUs.
To prevent these issues, when all reaper threads are busy, lmkd will
send a SIGKILL but will not synchronously reap the memory of the target
process.
Bug: 238495258
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I351c01229152946969e646b538a2494656c0cc85
Setting cpusets and priorities for the kill target involves fs operations
which can block on kernel internal locks. Doing that from lmkd main thread
context has the danger of blocking lmkd. With the introduction of the
reaper threads the time for the target to exit is not as critical since
its memory is freed by the reaper thread.
To prevent lmkd from being blocked, move setting cpuset for the kill
target into the reaper thread and remove priority setting logic with
heavy use of procfs reads.
Bug: 238495258
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I5defc6baa4ff1425d9835371b47a64e375ebac10
Reaper threads can take considerable time to free target's
memory running at RT priority that they inherit from LMKD.
This might prevent other critical tasks from being scheduled
while reaper threads are active.
Explicitly set reaper threads to run under normal scheduling
policy but set their nice value to ANDROID_PRIORITY_HIGHEST.
Bug: 237180716
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Idad817e698ae1d5ac6cee5aa3281c69c7e0d257f
Fix the text of the warning when pthread_setschedparam fails to set
SCHED_OTHER scheduling policy for a reaper thread.
Bug: 237180716
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I1b04713d145f4f3c243f16f932c753f5b06d48e6
Reaper threads can take considerable time to free target's
memory running at RT priority that they inherit from LMKD.
This might prevent other critical tasks from being scheduled
while reaper threads are active.
Explicitly set reaper threads to run under normal scheduling
policy but set their nice value to ANDROID_PRIORITY_HIGHEST.
Bug: 237180716
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Idad817e698ae1d5ac6cee5aa3281c69c7e0d257f
set_process_group_and_prio sets task profiles for each thread in the
process separately. This can be avoided by setting task profiles to
the entire process using its pid.
Bug: 215557553
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I9c1917172019a42809385f6c9c084b8cb343b520
To detect lmkd being stuck on a syscall for prolonged period of time,
introduce a watchdog thread which gets set when lmkd starts handling of
events and is reset after handling is done. If it takes more than the
timeout period (2 sec) to handle an event, watchdog wakes up and kills
the least important process to prevent mounting memory pressure caused
by lmkd lockup. After a kill, watchdog will wait for the reset for
another timeout period and kill again. This repeats until lmkd unlocks
and resets the watchdog.
Bug: 201671997
Test: induce random sleep in lmkd main handler and observe watchdog kills
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I56a55834582e11c06cc6cf9da3bc7380e634b301
process_mrelease syscall can be used to expedite memory release of
a process after it was killed. This allows memory to be released
without the target process being scheduled, therefore does not depend
on target's priority or the CPU it's running on.
However process_mrelease syscall can take considerable time. Blocking
lmkd main thread during that time can cause memory pressure events
being missed while lmkd is busy reaping previous target's memory.
For this reason reaping should be done in a separate thread. This way
lmkd main thread can keep monitoring memory pressure while memory is
being released.
Introduce Reaper class which maintains a pool of threads to perform
process killing and reaping. The main thread submits a request to the
Reaper to kill and reap the process without blocking. If all the threads
in the pool are busy at the time the next kill is needed, the kill is
performed by the main thread without reaping.
Bug: 130172058
Bug: 189803002
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: If7b10fdd1838bdfeea3fed3031565feffe0b52be
Suren Baghdasaryan
Xin Li