Current test will fail in the case when the target process exits before
process_mrelease is called. However this is possible and should not be
treated as an invalid case. Add special handling of this case in the
test.
Bug: 254880957
Test: run lmkd_tests until this case happens
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Ica5b28fa52a5f42a771fb9516112e58b66291068
Merged-In: Ica5b28fa52a5f42a771fb9516112e58b66291068
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
Merged-In: Ib4665d3df62f58e36686ca134f9ae07836fd6945
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
Merged-In: I5defc6baa4ff1425d9835371b47a64e375ebac10
Current test will fail in the case when the target process exits before
process_mrelease is called. However this is possible and should not be
treated as an invalid case. Add special handling of this case in the
test.
Bug: 254880957
Test: run lmkd_tests until this case happens
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Ica5b28fa52a5f42a771fb9516112e58b66291068
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
In the case of ZRAM, SwapFree does not represent the actual free swap
amount because swap space is taken from the free memory or reclaimed.
Therefore use free memory and easily reclaimable memory as an
approximation of how much free swap system can use. Use SwapFree as
a measure of how much swap space the system will consider using. Min
of those two measurements is used to decide how much usable swap the
system still has.
Bug: 238495258
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Ia7b0cc4a744d14c0d6e52603795917cf5824ea15
pid_remove() is not a thread-safe function and can be called only from
the main thread. Calling it from the watchdog_callback() executed in the
context of the watchdog thread can cause a use-after-free failure if the
same record is being used by the main thread. Fix this issue by marking
the process record as invalid instead of destroying it. Later on invalid
records will be cleared in kill_one_process() called from the context of
the main thread.
Fixes: f8727745f9 ("lmkd: Remove process record after it is killed by lmkd watchdog")
Bug: 248448498
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I0c7776aea1518c17f0a29904a44b7fe8f33980ca
pid_remove() is not a thread-safe function and can be called only from
the main thread. Calling it from the watchdog_callback() executed in the
context of the watchdog thread can cause a use-after-free failure if the
same record is being used by the main thread. Fix this issue by marking
the process record as invalid instead of destroying it. Later on invalid
records will be cleared in kill_one_process() called from the context of
the main thread.
Fixes: f8727745f9 ("lmkd: Remove process record after it is killed by lmkd watchdog")
Bug: 248448498
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I0c7776aea1518c17f0a29904a44b7fe8f33980ca
After lmkd watchdog kills a process, its record should be removed.
Bug: 243567425
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I70bb2a432df8088ebc9865fbc36b065738248d19
After lmkd watchdog kills a process, its record should be removed.
Bug: 243567425
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I70bb2a432df8088ebc9865fbc36b065738248d19
We already emit a richer slice (including pid and oom score) so there's
no reason for the additional print event
Bug: 195085238
Change-Id: I1140f0287934e5f0abdeeb64554a249c4c940def
Suren Baghdasaryan
Xin Li
Ioannis Ilkos