While troubleshooting memory pressure related issues it's hard to get a
good view of the memory state when lmkd kill happens. Logging relevant
information from /proc/meminfo file that was used to make a kill decision
is very helpful for further analysis. To do this efficiently we are using
Android Logger event library functions and log the data used for kill
decision after the kill signal was issued.
Test: Run lmkd_unit_test and logcat -b events -v descriptive
Change-Id: Id5de41b9d91a04dd5d3eb9b85d4e1babe9755628
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
1. let logs be written to statsd directly like all other stats logs.
+ stats log should not write to logd anymore(b/78239479)
2. fixed the log format
+ need to embed the elapsed real time in the log
3. fixed the log context reuse problem
+reset the log context buffer and internal state before reuse
Bug: 78603347
Bug: 78239479
Test: tested with alloc_stress, and saw logs written to statsd
performance measurement (memory & cpu):
https://paste.googleplex.com/5508158646648832
Change-Id: I345f0eace8ba1687ff480fb88e9abba1d8533f76
Move process initialization, mlockall() and sched_setscheduler() to
only occur if initialization succeeds and is enabled. This
conserves mlock'd memory and a FIFO processing slot if (deprecated)
kernel lowmemorykiller is active.
Cleanup: Android coding standard compliance.
Test: lmkd_unit_test
Bug: 33808187
Bug: 72838192
Change-Id: I51af0235c8eca4ef958ef2d83a8071ff58b49d78
(cherry pick from commit 0f1005180513e880bf7c90a3f2c2bf1a36aa1406)
A number of tools and tests require communication with lmkd.
In order to avoid code duplication liblmkd_utils implements
functions commonly used when interacting with lmkd process.
Isolate communication protocol details into lmkd.h
Bug: 63631020
Change-Id: Id840983d55b7db60013d52dee0c3187943811822
Merged-In: Id840983d55b7db60013d52dee0c3187943811822
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
(cherry pick from commit c71355991d4bafb4694f6252ac10e288a5fb9f75)
For tracing lmkd kills inside kernel it is useful to have traces
indicating when and which process lmkd is killing. By default the
tracing is disabled.
Bug: 63631020
Test: alloc-stress
Change-Id: I3ceb2bde0c292eec55855cb4535927f3b4c5d08b
Merged-In: I3ceb2bde0c292eec55855cb4535927f3b4c5d08b
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
It implements logging of following atoms:
-- LMK_STATE_CHANGED
-- LMK_KILL_OCCURRED
We would like to gather memory metrics of the process killed by LMKD
because by gathering this info we would be able to analyze and improve
system health by potentially reducing memory footprint of the process.
This feature would be available on production builds.
To know more about this see: http://go/android-p-memory-metrics
Bug: 65738734
Test: Tested manually
Change-Id: I064e0cdcb47c3b4c95d8b8d5654050c9812008d8
A number of tools and tests require communication with lmkd.
In order to avoid code duplication liblmkd_utils implements
functions commonly used when interacting with lmkd process.
Isolate communication protocol details into lmkd.h
Bug: 63631020
Change-Id: Id840983d55b7db60013d52dee0c3187943811822
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
For tracing lmkd kills inside kernel it is useful to have traces
indicating when and which process lmkd is killing. By default the
tracing is disabled.
Bug: 63631020
Test: alloc-stress
Change-Id: I3ceb2bde0c292eec55855cb4535927f3b4c5d08b
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Suren Baghdasaryan
Yao Chen
Mark Salyzyn
Rajeev Kumar
Daniel Colascione
Steven Moreland