On Thu 09-12-21 08:24:04, Suren Baghdasaryan wrote: > On Thu, Dec 9, 2021 at 1:12 AM Michal Hocko <mhocko@xxxxxxxx> wrote: > > > > Do we want this on top? > > As we discussed in this thread > https://lore.kernel.org/all/YY4snVzZZZYhbigV@xxxxxxxxxxxxxx, > __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. -- Michal Hocko SUSE Labs
