proc_get_name() can return NULL if the corresponding process has died
or open fails with ENOMEM due to memory shortages.
Ensure such cases are handled without NULL pointer access.
Bug: 186157675
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I05b288e3808bec0bdb73db32de02ba3a322ca6e1
(cherry picked from commit e5995b8269)
Occasionally a system can get into heavy file cache thrashing situation
and become unresponsive. In these situations we observe lmkd wakeups,
however it does not kill because all non-perceptible apps are already
killed and the system manages to reclaim enough memory to stay above
min watermark.
Add ro.lmk.thrashing_limit_critical property which when breached will
allow lmkd to kill perceptible apps. The property represents the
percentage of refaulted workingset pages as a fraction of overall file
cache size. By default it is disabled.
Bug: 181778155
Test: thrashing.py 500 10 200
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Merged-In: Icb38ef6c90adaa4f5c956593b6ea0c4febc91dc0
Change-Id: Icb38ef6c90adaa4f5c956593b6ea0c4febc91dc0
When killing a task at or lower than oom_score_adj PERCEPTIBLE_APP_ADJ
choose the heaviest task among the ones at that level to try minimizing
the number of required kills. Because killing a perceptible app will
affect user experience anyway, it makes sense to choose the one that
will release the most memory and therefore no more kills might be
necessary.
Bug: 181778155
Test: running thrashing.py script
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Merged-In: I775ff774430b6fde4d619ede794825dbae59fd8e
Change-Id: I775ff774430b6fde4d619ede794825dbae59fd8e
Information like free memory and swap as well as kill reason would be
useful for understanding regressions in the number of lmk kills in the
field.
Bug: 168117803
Test: statsd_testdrive 51, load with lmk_unit_test
Merged-In: Ic46aed3c85b880b32ac5ad61b55f90e0d33517c7
Change-Id: Ic46aed3c85b880b32ac5ad61b55f90e0d33517c7
If the first PSI event triggers a kill, lmkd won't resume polling
immediately after the process has died. Instead, it will wait until the
next PSI event to resume the polling which is too late when the device
is under memory pressure. This happens if data communication with AMS
happens after previous polling window expired, in which case paused
handler gets reset and polling does not resume after the kill.
Fix this by changing pause handler reset logic.
Bug: 167562248
Test: memory pressure test
Signed-off-by: Martin Liu <liumartin@google.com>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Merged-In: I10c65c85b718a656e3d8991bf09948b96da895cb
Change-Id: I10c65c85b718a656e3d8991bf09948b96da895cb
It seems we have chance that file_base_lru is zero.
Avoid it by adding 1.
Bug: 167660459
Bug: 163134367
Test: boot
Signed-off-by: Martin Liu <liumartin@google.com>
Merged-In: If19dbbaafe6cd28a9d5b7f8a002f3cd33daab5e7
Change-Id: If19dbbaafe6cd28a9d5b7f8a002f3cd33daab5e7
When a device is thrashing the file cache, workingset refaults can
grow slowly because of variant reasons. Current thrashing detection
mechanism could reset the thrashing counter frequently as it relies
on presence of reclaim activity, however refaults can keep increasing
even when the device is not actively reclaiming. In addition, the
thrashing counter gets reset when conditions require a kill but lmkd
could not find an eligible process to be killed. This is problematic
because when this happens thrashing is being ignored.
Use a fixed 1 sec periods to aggregate the thrashing counter. Also we
need to keep monitoring thrashing counter while retrying as someone
could release the memory to mitigate the thrashing. If thrashing
counter is greater than the limit at the end of the 1 sec period this
means lmkd failed to find an eligible process to kill. In this case
we store accumulated thrashing in case a new eligible process appears
until accumulated thrashing is less that the limit or we miss an
entire 1 sec window.
Bug: 163134367
Test: heavy loading launch
Signed-off-by: Martin Liu <liumartin@google.com>
Merged-In: Ie9f4121ea604179c0ad510cc8430e7a6aec6e6b2
Change-Id: Ie9f4121ea604179c0ad510cc8430e7a6aec6e6b2
This reverts commit 95551f816a.
Reason to revert: don't need this change.
Bug: 163134367
Signed-off-by: Martin Liu <liumartin@google.com>
Change-Id: I8b209b054b6caec553bce13cd51f931401c1e42a
When swap is depleted file cache thrashing might result in allocations
quickly pushing memory below low watermark and kswapd quickly pushing
it back above high watermark. In this situation free memory stays above
high watermark most of the time and lmkd during its periodic wake-ups
has low chance of detecting low memory conditions. Add a 15% margin
for high watermark which would allow lmkd to kill if swap is low,some
memory was reclaimed since the last wakeup and free memory is just
above the high watermark limit.
Bug: 163134367
Test: heavy loading launch
Signed-off-by: Martin Liu <liumartin@google.com>
Change-Id: I5694736b04bafcd13c01f4b51e242e2ac4ff55a8
Oftentimes while investigating bugreports it's unclear whether lmkd
was active between kills. To provide visibility into lmkd activity
adding the following fields into killinfo reports:
MsSinceEvent - number of msecs since the last PSI/vmpressure event
MsSincePrevWakeup - number of msecs since the previous wakeup
WakeupsSinceEvent - number of wakeups since the last PSI/vmpressure
event
SkippedWakeups - number of wakeups that were skipped due to an
incomplete kill
Bug: 162034541
Bug: 161955028
Bug: 162297751
Test: lmkd_unit_test
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I0356c27515132ff0dd309b59a8bf907acbd67cd8
(cherry picked from commit d7b4fcb8a5)
Signed-off-by: Martin Liu <liumartin@google.com>
Merged-In: I0356c27515132ff0dd309b59a8bf907acbd67cd8
When lmkd tries to kill a process in uninterruptible sleep state, it may
need to wait for a long time. To prevent this set the default kill timeout
to 100ms which should work for majority of the devices.
Bug: 160295034
Bug: 161955028
Bug: 162297751
Test: lmkd_unit_test
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Ia280dc095df9ca8494278e0a75b976ed93fc04ae
(cherry picked from commit 7d1f4f0047)
Signed-off-by: Martin Liu <liumartin@google.com>
Merged-In: Ia280dc095df9ca8494278e0a75b976ed93fc04ae
Fix code logic to obey our intetion of not killing perceptible apps
due to low swap if above min wmark.
Bug: 155709603
Test: boot
Signed-off-by: Martin Liu <liumartin@google.com>
Merged-In: Ifc09c2a1fe7e21faa096988f471644f63951d81c
Change-Id: Ifc09c2a1fe7e21faa096988f471644f63951d81c
Prevent kills of perceptible apps due to swap shortages unless system
free memory is below the min watermark. This prevents kills of important
apps when the system is recovering from the memory pressure.
Bug: 155709603
Test: memory stress test with multiple foreground apps
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Merged-In: I6beb4b55f8b4f7bc22818b5a7bdfa3adc6cd31c1
Change-Id: I6beb4b55f8b4f7bc22818b5a7bdfa3adc6cd31c1
Lower the min swap threshold to 10% for all devices to limit kills while
swap still has enough space.
Bug: 155709603
Test: memory stress test with multiple foreground apps
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I443486763c034ed0603ea52b81c060c3969af9a5
In the cases when foreground processes should not be killed
min_score_adjust should be set above PERCEPTIBLE_APP_ADJ to prevent such
kills.
Bug: 155709603
Test: memory stress test with multiple foreground apps
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: If187654b8001ce843ec6085ccd2042d75a986dae
Allow lmkd to stop waiting for a kill notification if a kill takes longer
than ro.lmk.kill_timeout_ms.
Bug: 147315292
Test: lmkd_unit_test with ro.lmk.kill_timeout_ms set to 100
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Merged-In: Ia3eed3448fd6928a5e634c2737044722048b3578
Change-Id: Ia3eed3448fd6928a5e634c2737044722048b3578
Add --reinit command-line option to allow updating lmkd properties. For
example to enable debug logging in the running lmkd process user should
issue:
setprop ro.lmk.debug true
lmkd --reinit
Bug: 155149944
Test: lmkd_unit_test after resetting lmkd properties
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Merged-In: Ic60331f3368f5a7fdfe09ad7d47c7ccf0a497685
Change-Id: Ic60331f3368f5a7fdfe09ad7d47c7ccf0a497685
Use the autogenerated libstatslog_lmkd to send events to statsd
The logging schema for statsd is changing as part of statsd becoming
a Mainline module in R. The autogenerated code will handle the schema
change.
Bug: 145887874
Test: m -j
Test: atest android.cts.statsd.atom.UidAtomTests#testLmkKillOccurred
Change-Id: Ibae4cd822807369a799d5c1f6a9c51272e38a074
lmkd unsolicited notifications can cause lmkd to block if clients are not
consuming them. Fix that by sending notifications to only subscribed
clients. Introduce LMK_SUBSCRIBE command to allow lmkd clients to subscribe
to event notifications. The only asynchronous event currently supported is
LMK_ASYNC_EVENT_KILL.
Bug: 146597855
Test: fill up send buffer using lmkd_unit_test
Test: confirm lmkd does not block after the fix
Change-Id: I014159aa55b59081f4b9ed53ecd160a49c0682bb
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Suren Baghdasaryan
Martin Liu
Muhammad Qureshi
Tom Cherry