Make vendor_available = true so that other modules in vendor image
can leverage this library to init, register and unregister to psi.
Bug: 169346507
Change-Id: I47f7d25984e09d61703e7b2bd6fcb8db9d3814f5
Signed-off-by: Sudarshan Rajagopalan <sudaraja@codeaurora.org>
The libpsi source code is missing cutils and stdio header files.
Add cutils and stdio header files, and add libcutils_headers to
the header library in Android.bp.
Bug: 169346507
Change-Id: I2d613d5724d3c5f52dd52dcae7024439f2e8d5bb
Signed-off-by: Sudarshan Rajagopalan <sudaraja@codeaurora.org>
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
Change-Id: Ic46aed3c85b880b32ac5ad61b55f90e0d33517c7
Test: statsd_testdrive 51, load with lmk_unit_test
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>
Change-Id: I10c65c85b718a656e3d8991bf09948b96da895cb
It seems we have chance that file_base_lru is zero.
Avoid it by adding 1.
Bug: 167660459
Test: boot
Signed-off-by: Martin Liu <liumartin@google.com>
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>
Change-Id: Ie9f4121ea604179c0ad510cc8430e7a6aec6e6b2
Changes:
- We are already reading /proc/pid/status to resolve the tgid. While we
are at it, also parse RSS and swap values.
- Use the RSS and swap values for non memcg builds when creating the
statsd outputs
- Given we already read RSS, remove the separate read of /proc/pid/statm
that used to get tasksize.
Bug: 163116785
Test: manual, out/host/linux-x86/bin/statsd_testdrive 51
Change-Id: I9d98b9ffe8be0b014bb09174ec9532382cae1f38
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
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
Test: lmkd_unit_test
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: 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
Test: lmkd_unit_test
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: 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
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
am skip reason: Change-Id I6beb4b55f8b4f7bc22818b5a7bdfa3adc6cd31c1 with SHA-1 48135c4cba is in history
Change-Id: I991c035d1cf12e59b5975450b399a85d0af239ab
am skip reason: Change-Id I6beb4b55f8b4f7bc22818b5a7bdfa3adc6cd31c1 with SHA-1 48135c4cba is in history
Change-Id: I742875df19599c98274531e9d986f3a827529da5
am skip reason: Change-Id I6beb4b55f8b4f7bc22818b5a7bdfa3adc6cd31c1 with SHA-1 48135c4cba is in history
Change-Id: Ia2bbfb9829b21d0214279edc7c245b5437d31593
am skip reason: Change-Id I443486763c034ed0603ea52b81c060c3969af9a5 with SHA-1 c2b228e498 is in history
Change-Id: I16423e56f3e6fb693b5fa285b03a94763fe90990
am skip reason: Change-Id If187654b8001ce843ec6085ccd2042d75a986dae with SHA-1 0e589f61ba is in history
Change-Id: I465380f7a63d085ab082582d6a0cf2a3a2527e77
am skip reason: Change-Id I443486763c034ed0603ea52b81c060c3969af9a5 with SHA-1 c2b228e498 is in history
Change-Id: I320b9b413fddfcc2ddd5dfbe2a3683dc5e5abae9
am skip reason: Change-Id If187654b8001ce843ec6085ccd2042d75a986dae with SHA-1 0e589f61ba is in history
Change-Id: I007c16b6a8bc5de7a906b8ab4424d42212f5b3ce
Kalesh Singh
Xin Li
Sudarshan Rajagopalan
Suren Baghdasaryan
Martin Liu
Ioannis Ilkos
Automerger Merge Worker