Thread (14 messages) 14 messages, 2 authors, 2021-12-16

Re: [PATCH 4/3] mm: drop MMF_OOM_SKIP from exit_mmap

From: Suren Baghdasaryan <surenb@google.com>
Date: 2021-12-09 17:07:12
Also in: lkml

On Thu, Dec 9, 2021 at 8:47 AM Michal Hocko [off-list ref] wrote:
On Thu 09-12-21 08:24:04, Suren Baghdasaryan wrote:
quoted
On Thu, Dec 9, 2021 at 1:12 AM Michal Hocko [off-list ref] wrote:
quoted
Do we want this on top?
As we discussed in this thread
https://lore.kernel.org/all/YY4snVzZZZYhbigV@dhcp22.suse.cz (local),
__oom_reap_task_mm in exit_mmap allows oom-reaper/process_mrelease to
unmap pages in parallel with exit_mmap without blocking each other.
Removal of __oom_reap_task_mm from exit_mmap prevents this parallelism
and has a negative impact on performance. So the conclusion of that
thread I thought was to keep that part. My understanding is that we
also wanted to remove MMF_OOM_SKIP as a follow-up patch but
__oom_reap_task_mm would stay.
OK, then we were talking past each other, I am afraid. I really wanted
to get rid of this oom specific stuff from exit_mmap. It was there out
of necessity. With a proper locking we can finally get rid of the crud.
As I've said previously oom reaping has never been a hot path.

If we really want to optimize this path then I would much rather see a
generic solution which would allow to move the write lock down after
unmap_vmas. That would require oom reaper to be able to handle mlocked
memory.
Ok, let's work on that and when that's done we can get rid of the oom
stuff in exit_mmap. I'll look into this over the weekend and will
likely be back with questions.
Thanks!
--
Michal Hocko
SUSE Labs
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help