When a proc list for an oomadj is non-empty, we currently read
from disk to get the size of every process in our list, so we
can know which is the largest/heaviest process.
However, if there's only a single process in our list, we already
know it's going to be our heaviest [*]. So we don't need to do
the (relatively expensive) disk access to figure out its size,
and can just directly return this process.
[*] There's the case where our attempt to read from /proc fails
for the process. The old code would then instantly remove this
stale pid (and return NULL if that was the only process in the
list). This new code will end up returning this stale process
instead. Since proc_get_heaviest() is meant to be used in the
same way as proc_adj_tail(), and proc_adj_tail() returns
processes without checking if they are stale, we don't consider
this an issue. (Note that in the current code, the only calling
site of proc_get_heaviest() will remove this stale process when
it calls kill_one_process().)
Bug: 405391096
Test: TreeHugger
Change-Id: Iaf2f5c57dcbf2d4e45c2545a8322736b5985337c
This change allows vendors to trigger LMKD kill events with custom
reasons and minimum score adjustments. This enables experimentation
with custom heuristics and data collection for evaluation before
upstreaming changes to AOSP.
Bug: 385050909
Test: build and check the vendor kill event
Change-Id: If9b51ed9603f0e10e6fc4671fb6da26548f41aaf
Merged-In: If9b51ed9603f0e10e6fc4671fb6da26548f41aaf
Signed-off-by: Martin Liu <liumartin@google.com>
Summary: As a good practice, let's make sure that the "kill_desc" buffer is always null-terminated, even if its size changes in the future.
Test: Successful build on master.
Change-Id: I68a0dc346ea26126a1581994f9c508980a6ac408
Signed-off-by: Abdelrahman Daim <adaim@meta.com>
LMKD was woken up when the memory pressure was high enough either in
either the psi or the vmpressure mechanism. The memory reclaim ability
is based on CPUs' capacity of a chip and it is different from each
others. This patch can count the number of lmkd wake up when meet the
memory pressure threshold instead of heavy-loading logging. To show the
count, we can just re-init the lmkd, and it will print in the android
logcat and reset the count to zero.
Test: Run APP rotation
Bug: 365748420
Signed-off-by: JohnHsu <john.hsu@mediatek.com>
Change-Id: I3980d2a90a910c64449b4ad2b005e4d0437097e8
When both Medium and Critical events occur at same time,
depending on how the events are queued, the later event
resets the former event.
We'd want the subsequent polling (till next event is triggered)
to happen with higher event.
So, it is fine if Critical event overrides Medium, but not other
way around.
Let's see below scenario where both Medium and Critical events
occur (at T0) and handled one after other
T0: critical event handled.
T0 + 2ms: medium event handled.
T0 + 102ms: medium event polling check. //This should be critical poll
Bug: 376003899
Change-Id: I16ff3b999d7531435324a628ac17968fd4cae8cf
When a new event occurs (could be of same level or different,
doesn't matter) after a event-poll is handled, poll of new event
waits only for "100ms - time since last poll is handled".
But new poll should start after 100ms of last triggered event.
T0: event-1 triggered.
T100: event-1 polled
T120: event-2 triggered.
T200: event-2 polled. (This poll should happen 100ms after T120, i.e., T220)
Bug: 377418039
Change-Id: I10aace061668adfed2594581b94cb9f1e745820b
The kernel will print node stats within the first populated zone in the
zoneinfo file. The LMKD tries parsing node stats when it reads the first
"Node %d, zone %8s" line in zoneinfo.
However if the first zone is empty, LMKD could iterate over to the next
populated zone i.e. the next "Node %d, zone %8s" line while attempting
to read node stats. It thus reads the incorrect zone name for this next
zone.
To fix this, ensure whether node stats are indeed being parsed by
checking for the " per node-stats" line.
Bug: 292476676
Change-Id: I72cd111dac9032de506e1ab7f1c4dc96585a1e80
Signed-off-by: Jaskaran Singh <quic_jasksing@quicinc.com>
Recent kernel change [1] cause pidfd_wait() to receive EPOLLHUP when the
task exits. Current LMKD implementation expects to receive EPOLLHUP only
when socket connection gets dropped, therefore it gets confused by this
new kernel behavior. Adjust LMKD handling of EPOLLHUP to detect the case
when this event is generated by pidfd.
[1] https://lore.kernel.org/all/20240202131226.GA26018@redhat.com/
Bug: 352286227
Change-Id: Ibcf349ee3cc73551541d64975f0292d53c41d5c2
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Add a hook that is invoked when there are no killable processes at any
priority. This allows ARCVM to send VMMMS's no kill candidates message,
which prevents thrashing without having to wait on a balloon stall.
Bug: 362383831
Test: cq
Change-Id: Iffb680a78025bd201932bd805ceeecfe07b1fac9
Add RSS field, in LMK_PROCKILL cmd, to report the latest memory usage of
the killed process.
Test: Verified RSS field is captured in ApplicationExitInfo
Bug: 322549716
Change-Id: Ic1788e8121da97cd879bd7e9d685c7b879ea5475
Signed-off-by: Carlos Galo <carlosgalo@google.com>
When we get nothing from /proc/<PID>/status and /proc/<PID>/cmdline,
we should return NULL or False because this usually indicates the
process has already terminated. We should avoid attempting
to kill a non-existent process, as it's an unnecessary waste
of kill timeout.
Bug: 331612600
Test: give memory pressure to trigger LMKD
Change-Id: I468ff25012f9bb6fc842a7fad268ebcad0de4690
Signed-off-by: Martin Liu <liumartin@google.com>
Experiments on low-RAM devices indicate regressions due to the new low
memory kill reason which cause LMKD to kill too many processes. Change
ro.lmk.lowmem_min_oom_score to disable kills for this reason by default.
Bug: 341257415
Change-Id: Id7137c4c8d888061353b253dc6906d2854e31b1d
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
We are trying to remove BPF_FD_JUST_USE_INT since we now have access to
libbase everywhere.
Test: builds
Change-Id: Ie9445d3d648e6837deb718aa38ebef3c936653d6
Integrate io_uring within LMKD to batch the read, and write, system
calls needed to process, and register, processes and adjust their OOM
scores.
Test: atest lmkd_tests
Bug: 325525024
Change-Id: I339be2b6f569189519e0e11d07cd6d7d1cf2566d
Signed-off-by: Carlos Galo <carlosgalo@google.com>
Adjusting the string copy message to utiilize the correct format for
direct_reclaim_duration_ms.
Test: m
Bug: 244232958
Change-Id: I3fbfc33e2520ef38b829db67ddb59c636a2bc3e1
Signed-off-by: Carlos Galo <carlosgalo@google.com>
Creating new cmd in LMKD to batch PROCPRIO requests.
Test: atest lmkd_tests
Bug: 325525024
Change-Id: I5460446d4e968e80263aa25298e2a893863eece4
Signed-off-by: Carlos Galo <carlosgalo@google.com>
Refactor cmd_procprio() to reuse its main functionality for bulk updates
later on.
Test: m
Bug: 295231583
Change-Id: Ic42de6e256b813349530f19a20e3ef9d484b20cf
Signed-off-by: Carlos Galo <carlosgalo@google.com>
Updating the cmd_procprio function with the clang-format suggestions. No logic changes.
Test: m
Bug: 325525024
Change-Id: Id6c1feb717259406d953e5e2a174398bccf65d23
Signed-off-by: Carlos Galo <carlosgalo@google.com>
Moving logic for registering proc, after oom adjustment, to its
own function. This work is for the introduction of the new
PROCS_PRIO cmd. This logic will be shared between the current PROCPRIO
and PROCS_PRIO cmd.
Test: m
Bug: 325525024
Change-Id: I0683f63faa3dfa2e4534cdfb8935b4d2f83a6af9
Signed-off-by: Carlos Galo <carlosgalo@google.com>
All the PATH_MAX usages are used to store proc/<pid>/filename
information in lmkd. PATH_MAX is 4096, which is an overkill
of buffer sizes for their usage. Replace PATH_MAX with a smaller size.
Test: m
Bug: 325525024
Change-Id: If6d500102fca532a8afc331d0c847675d6e9e96f
Signed-off-by: Carlos Galo <carlosgalo@google.com>
Current lmkd behavior to kill cached apps when free memory hits low
watermark threshold does not work well on certain devices where more
or less aggressive behavior would yield better results. Introduce a
tunable to control the min oom_score_adj level at which lmkd considers
to kill processes when the system gets into this state. The default
value is set to 701 which preserves the current behavior of killing
cached apps except for the last active one. Setting it to lower values
will make more processes eligible to be killed, setting it to higher
values will limit the kills to a smaller set of processes. Setting it
to 1001 will prevent any process from being killed for this reason.
Bug: 334867461
Bug: 337063274
Change-Id: I1447436e0a0cd1e696b34d2c06b92ff73a5100a9
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Update the init_psi_monitor API to monitor MEMORY, IO, and CPU
resources.
Test: m libpsi
Bug: 335872571
Change-Id: Ieae8c98be0e6353a1d0ca0728c84bcf1897b259c
Free swap is calculated using the min of free swap that kernel would
consider using and easily available memory which can be used by ZRAM
for swapping purposes. However calculation does not consider the
average data compression ratio of ZRAM. Introduce a tunable to set
the average swap compression ratio used when evaluating the amount
of data which can be swapped. Default is set to 1 (no compression)
to keep current behavior. Setting it to 0 will ignore available memory
and assume that configured swap size can be always utilized fully.
Bug: 285854307
Bug: 327561101
Change-Id: I6b0f93ce24179ebf7365a3dbcd52c6e4a52ac200
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Replacing mechanism of reading vmstats to detect kswapd with
memevents instead. Maintain vmstats mechanism if bpf is not supported by
current kernel.
Test: Verified lmkd receives kswapd state changes
Test: m
Bug: 330606003
Change-Id: I9b980a8b94e015d1b8e0986fff9113890420d102
Signed-off-by: Carlos Galo <carlosgalo@google.com>
This monitoring will no longer only track direct reclaim state changes.
Adjusting naming to reflect the broader utilization.
Test: m
Bug: 330606003
Change-Id: Ib77b8b58cd6e8ce1296ffa14481018c29e979754
Signed-off-by: Carlos Galo <carlosgalo@google.com>
Add new command to allow for post-boot actions to occur. This
will allow for the MemEventListener to start after the BPF files are
loaded, removing the need to stall during boot-up until they are loaded
in the device.
Test: Verified memevent listener initialized post-boot
Test: Verified LMKD no longer stalls until BPF progs are loaded
Bug: 331008250
Bug: 244232958
Change-Id: I55f97b41349ea7693cff81b1170d33712b820292
Signed-off-by: Carlos Galo <carlosgalo@google.com>
Add kill reason for when the device is stuck in direct reclaim for
longer than the configurable threshold. Only allow configurable
threshold, and direct reclaim stuck detection, if memevents direct
reclaim monitoring is enabled.
Test: Verified direct reclaim stuck kill log with memory pressure test
Test: m
Bug: 244232958
Change-Id: I1156899874d2eb7e0f4b61597741087c110b3414
Signed-off-by: Carlos Galo <carlosgalo@google.com>
Replacing mechanism of reading vmstats to detect direct reclaim with
memevents instead. Maintain vmstats mechanism if bpf ring buffer is not
supported by current kernel.
Test: Verified lmkd receives direct reclaim state changes
Test: m
Bug: 244232958
Change-Id: I59ee7657da1240355d611dfa129c4d50bed2c330
Signed-off-by: Carlos Galo <carlosgalo@google.com>
Adjust lmk cycle after kill to honor an optional min score.
Test: cycle after kill under mem pressure honors specified score
Bug: 309380316
Change-Id: I9ab8e29b58846cc291acb2834638ddf7a7759eca
Signed-off-by: Matt Stephenson <stephensonmatt@google.com>
Add kill reason for a cached app kill when free memory is under low
watermark.
Bug: 306755741
Change-Id: Idf92da326f6e0990e6d9fd9acdd21b19f6bdd241
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
With Android U removing AMS kills, lmkd has additional duty to kill
cached apps which previously were killed by AMS. The former logic is
not proactive enough and leads to too many cached apps contributing
to memory pressure.
Implement additional logic to kill cached apps (excluding previous
foreground apps) when low watermark is breached or when device is
thrashing.
Bug: 300660611
Change-Id: I356eac1fe6d44dad292a7ea2fadee69a5be61479
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
As a result of experiments, the default relation between critical and
normal thrashing limits has been shown to be insufficient. Increase the
relation from 2x to 3x.
Bug: 194316048
Change-Id: I19877e0df56be07f3f503688f408f5f91f4b1e67
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
In rare cases it's possible that pgscan is not changing because inactive
LRU is empty and can't be refilled from the active LRU due to all
pages being hot. In such conditions pgscan_kswapd/pgscan_direct will
not change while pgrefill will be increasing due to active LRU being
scanned. Lmkd would incorrectly treat this situation as if no reclaim
activity happened.
Change lmkd to check pgrefill as well to detect such conditions.
Bug: 288383787
Change-Id: I6b49607429e2f673bba2645ccddff1a141afbcd1
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
To save CPU cycles during boot for low resource device a new
configuration is added to delay initialization of monitoring until boot
is complete.
Bug: 288566858
Test: Build, boot and verified boot logs to confirm the behavior.
Merged-In: I17cfbf4c7f83bc80dd92a99dfb0254a7e20289be
Change-Id: I17cfbf4c7f83bc80dd92a99dfb0254a7e20289be
The LmkStateChanged atom was historically used to mark lmk activity
and trigger additional stats polling. For more than a year this has
not been used at all (as statsd supported event-based triggering).
Remove unnecessary functionality.
Bug: 278174420
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I9f7f56711fabb751cf7a57ea7279759bcc4a3dff
Greg Kaiser
Martin Liu
Treehugger Robot
Abdelrahman Daim
JohnHsu
Divyanand Rangu
Jaskaran Singh
Suren Baghdasaryan
David Stevens
Carlos Galo
Christopher Ferris
Patrick Rohr
Lakshman Annadorai
Matt Stephenson
T.J. Mercier
Kalesh Singh
Lee George Thomas