linux.git/mm/oom_kill.c, branch v6.9

mm: update mark_victim tracepoints fields

2024-03-05T01:01:16+00:00

The current implementation of the mark_victim tracepoint provides only the
process ID (pid) of the victim process.  This limitation poses challenges
for userspace tools requiring real-time OOM analysis and intervention. 
Although this information is available from the kernel logs, it’s not
the appropriate format to provide OOM notifications.  In Android, BPF
programs are used with the mark_victim trace events to notify userspace of
an OOM kill.  For consistency, update the trace event to include the same
information about the OOMed victim as the kernel logs.

- UID
   In Android each installed application has a unique UID. Including
   the `uid` assists in correlating OOM events with specific apps.

- Process Name (comm)
   Enables identification of the affected process.

- OOM Score
  Will allow userspace to get additional insight of the relative kill
  priority of the OOM victim. In Android, the oom_score_adj is used to
  categorize app state (foreground, background, etc.), which aids in
  analyzing user-perceptible impacts of OOM events [1].

- Total VM, RSS Stats, and pgtables
  Amount of memory used by the victim that will, potentially, be freed up
  by killing it.

[1] https://cs.android.com/android/platform/superproject/main/+/246dc8fc95b6d93afcba5c6d6c133307abb3ac2e:frameworks/base/services/core/java/com/android/server/am/ProcessList.java;l=188-283
Signed-off-by: Carlos Galo 
Reviewed-by: Steven Rostedt 
Cc: Suren Baghdasaryan 
Cc: Michal Hocko 
Cc: "Masami Hiramatsu (Google)" 
Cc: Mathieu Desnoyers 
Signed-off-by: Andrew Morton

mm, oom:dump_tasks add rss detailed information printing

2023-12-11T00:51:53+00:00

When the system is under oom, it prints out the RSS information of each
process.  However, we don't know the size of rss_anon, rss_file, and
rss_shmem.

To distinguish the memory occupied by anonymous or file mappings
or shmem, could help us identify the root cause of the oom.

So this patch adds RSS details, which refers to the /proc//status[1].
It can help us know more about process memory usage.

Example of oom including the new rss_* fields:
[ 1630.902466] Tasks state (memory values in pages):
[ 1630.902870] [  pid  ]   uid  tgid total_vm      rss rss_anon rss_file rss_shmem pgtables_bytes swapents oom_score_adj name
[ 1630.903619] [    149]     0   149      486      288        0      288         0    36864        0             0 ash
[ 1630.904210] [    156]     0   156   153531   153345   153345        0         0  1269760        0             0 mm_test

[1] commit 8cee852ec53f ("mm, procfs: breakdown RSS for anon, shmem and file in /proc/pid/status").

Link: https://lkml.kernel.org/r/202311231840181856667@zte.com.cn
Signed-off-by: Yong Wang 
Reviewed-by: Yang Yang 
Cc: Hugh Dickins 
Cc: Johannes Weiner 
Cc: Xuexin Jiang 
Cc: Michal Hocko 
Signed-off-by: Andrew Morton

mm/oom_killer: simplify OOM killer info dump helper

2023-10-25T23:47:10+00:00

There is only one caller wants to dump the kill victim info, so just let
it call the standalone helper, no need to make the generic info dump
helper take an extra argument for that.

Result of bloat-o-meter:
./scripts/bloat-o-meter ./mm/oom_kill.old.o ./mm/oom_kill.o
add/remove: 0/0 grow/shrink: 1/2 up/down: 131/-142 (-11)
Function                                     old     new   delta
oom_kill_process                             412     543    +131
out_of_memory                               1422    1418      -4
dump_header                                  562     424    -138
Total: Before=21514, After=21503, chg -0.05%

Link: https://lkml.kernel.org/r/20231016113103.86477-1-ryncsn@gmail.com
Signed-off-by: Kairui Song 
Acked-by: Michal Hocko 
Cc: Christian Brauner 
Cc: Suren Baghdasaryan 
Signed-off-by: Andrew Morton

mm: remove redundant K() macro definition

2023-08-21T20:37:44+00:00

Patch series "cleanup with helper macro K()".

Use helper macro K() to improve code readability.  No functional
modification involved.  Remove redundant K() macro definition.


This patch (of 7):

Since commit eb8589b4f8c1 ("mm: move mem_init_print_info() to mm_init.c"),
the K() macro definition has been moved to mm/internal.h.  Therefore, the
definitions in mm/memcontrol.c, mm/backing-dev.c and mm/oom_kill.c are
redundant.  Drop redundant definitions.

[akpm@linux-foundation.org: oom_kill.c: remove "#undef K", per Kefeng]
Link: https://lkml.kernel.org/r/20230804012559.2617515-1-zhangpeng362@huawei.com
Link: https://lkml.kernel.org/r/20230804012559.2617515-2-zhangpeng362@huawei.com
Signed-off-by: ZhangPeng 
Reviewed-by: Matthew Wilcox (Oracle) 
Reviewed-by: David Hildenbrand 
Cc: Kefeng Wang 
Cc: Nanyong Sun 
Signed-off-by: Andrew Morton

mm, oom: do not check 0 mask in out_of_memory()

2023-06-09T23:25:20+00:00

Since commit 60e2793d440a ("mm, oom: do not trigger out_of_memory from the
#PF"), no user sets gfp_mask to 0.  Remove the 0 mask check and update the
comments.

Link: https://lkml.kernel.org/r/20230508073538.1168-1-haifeng.xu@shopee.com
Signed-off-by: Haifeng Xu 
Acked-by: Michal Hocko 
Cc: Johannes Weiner 
Cc: Shakeel Butt 
Signed-off-by: Andrew Morton

mm/mmu_notifier: remove unused mmu_notifier_range_update_to_read_only export

2023-02-03T06:32:54+00:00

mmu_notifier_range_update_to_read_only() was originally introduced in
commit c6d23413f81b ("mm/mmu_notifier:
mmu_notifier_range_update_to_read_only() helper") as an optimisation for
device drivers that know a range has only been mapped read-only.  However
there are no users of this feature so remove it.  As it is the only user
of the struct mmu_notifier_range.vma field remove that also.

Link: https://lkml.kernel.org/r/20230110025722.600912-1-apopple@nvidia.com
Signed-off-by: Alistair Popple 
Acked-by: Mike Rapoport (IBM) 
Reviewed-by: Jason Gunthorpe 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Mike Kravetz 
Cc: Ira Weiny 
Cc: Jerome Glisse 
Cc: John Hubbard 
Cc: Ralph Campbell 
Signed-off-by: Andrew Morton

mm: reduce noise in show_mem for lowmem allocations

2022-09-27T02:46:29+00:00

While discussing early DMA pool pre-allocation failure with Christoph [1]
I have realized that the allocation failure warning is rather noisy for
constrained allocations like GFP_DMA{32}.  Those zones are usually not
populated on all nodes very often as their memory ranges are constrained.

This is an attempt to reduce the ballast that doesn't provide any relevant
information for those allocation failures investigation.  Please note that
I have only compile tested it (in my default config setup) and I am
throwing it mostly to see what people think about it.

[1] http://lkml.kernel.org/r/20220817060647.1032426-1-hch@lst.de

[mhocko@suse.com: update]
  Link: https://lkml.kernel.org/r/Yw29bmJTIkKogTiW@dhcp22.suse.cz
[mhocko@suse.com: fix build]
[akpm@linux-foundation.org: fix it for mapletree]
[akpm@linux-foundation.org: update it for Michal's update]
[mhocko@suse.com: fix arch/powerpc/xmon/xmon.c]
  Link: https://lkml.kernel.org/r/Ywh3C4dKB9B93jIy@dhcp22.suse.cz
[akpm@linux-foundation.org: fix arch/sparc/kernel/setup_32.c]
Link: https://lkml.kernel.org/r/YwScVmVofIZkopkF@dhcp22.suse.cz
Signed-off-by: Michal Hocko 
Acked-by: Johannes Weiner 
Acked-by: Vlastimil Babka 
Cc: Christoph Hellwig 
Cc: Mel Gorman 
Cc: Dan Carpenter 
Signed-off-by: Andrew Morton

mm: delete unused MMF_OOM_VICTIM flag

2022-09-27T02:46:27+00:00

With the last usage of MMF_OOM_VICTIM in exit_mmap gone, this flag is now
unused and can be removed.

[akpm@linux-foundation.org: remove comment about now-removed mm_is_oom_victim()]
Link: https://lkml.kernel.org/r/20220531223100.510392-2-surenb@google.com
Signed-off-by: Suren Baghdasaryan 
Acked-by: Michal Hocko 
Cc: David Rientjes 
Cc: Matthew Wilcox 
Cc: Johannes Weiner 
Cc: Roman Gushchin 
Cc: Minchan Kim 
Cc: "Kirill A . Shutemov" 
Cc: Andrea Arcangeli 
Cc: Christian Brauner (Microsoft) 
Cc: Christoph Hellwig 
Cc: Oleg Nesterov 
Cc: David Hildenbrand 
Cc: Jann Horn 
Cc: Shakeel Butt 
Cc: Peter Xu 
Cc: John Hubbard 
Cc: Shuah Khan 
Cc: Liam Howlett 

Signed-off-by: Andrew Morton

mm: drop oom code from exit_mmap

2022-09-27T02:46:27+00:00

The primary reason to invoke the oom reaper from the exit_mmap path used
to be a prevention of an excessive oom killing if the oom victim exit
races with the oom reaper (see [1] for more details).  The invocation has
moved around since then because of the interaction with the munlock logic
but the underlying reason has remained the same (see [2]).

Munlock code is no longer a problem since [3] and there shouldn't be any
blocking operation before the memory is unmapped by exit_mmap so the oom
reaper invocation can be dropped.  The unmapping part can be done with the
non-exclusive mmap_sem and the exclusive one is only required when page
tables are freed.

Remove the oom_reaper from exit_mmap which will make the code easier to
read.  This is really unlikely to make any observable difference although
some microbenchmarks could benefit from one less branch that needs to be
evaluated even though it almost never is true.

[1] 212925802454 ("mm: oom: let oom_reap_task and exit_mmap run concurrently")
[2] 27ae357fa82b ("mm, oom: fix concurrent munlock and oom reaper unmap, v3")
[3] a213e5cf71cb ("mm/munlock: delete munlock_vma_pages_all(), allow oomreap")

[akpm@linux-foundation.org: restore Suren's mmap_read_lock() optimization]
Link: https://lkml.kernel.org/r/20220531223100.510392-1-surenb@google.com
Signed-off-by: Suren Baghdasaryan 
Acked-by: Michal Hocko 
Cc: Andrea Arcangeli 
Cc: Christian Brauner (Microsoft) 
Cc: Christoph Hellwig 
Cc: David Hildenbrand 
Cc: David Rientjes 
Cc: Jann Horn 
Cc: Johannes Weiner 
Cc: John Hubbard 
Cc: "Kirill A . Shutemov" 
Cc: Liam Howlett 
Cc: Matthew Wilcox 
Cc: Minchan Kim 
Cc: Oleg Nesterov 
Cc: Peter Xu 
Cc: Roman Gushchin 
Cc: Shakeel Butt 
Cc: Shuah Khan 
Signed-off-by: Andrew Morton

mm/oom_kill: use vma iterators instead of vma linked list

2022-09-27T02:46:25+00:00

Use vma iterator in preparation of removing the linked list.

Link: https://lkml.kernel.org/r/20220906194824.2110408-62-Liam.Howlett@oracle.com
Signed-off-by: Liam R. Howlett 
Acked-by: Vlastimil Babka 
Reviewed-by: Davidlohr Bueso 
Tested-by: Yu Zhao 
Cc: Catalin Marinas 
Cc: David Hildenbrand 
Cc: David Howells 
Cc: "Matthew Wilcox (Oracle)" 
Cc: SeongJae Park 
Cc: Sven Schnelle 
Cc: Will Deacon 
Signed-off-by: Andrew Morton