Re: [PATCH v9 2/2] mm/oom_kill: The OOM reaper traverses the VMA maple tree in reverse order

Michal Hocko
2025-09-11T07:31:38Z

On Thu 11-09-25 12:06:09, zhongjinji wrote:
> > On Wed 10-09-25 22:37:26, zhongjinji wrote:
> > > Although the oom_reaper is delayed and it gives the oom victim chance to
> > > clean up its address space this might take a while especially for
> > > processes with a large address space footprint. In those cases
> > > oom_reaper might start racing with the dying task and compete for shared
> > > resources - e.g. page table lock contention has been observed.
> > >
> > > Reduce those races by reaping the oom victim from the other end of the
> > > address space.
> > >
> > > It is also a significant improvement for process_mrelease(). When a process
> > > is killed, process_mrelease is used to reap the killed process and often
> > > runs concurrently with the dying task. The test data shows that after
> > > applying the patch, lock contention is greatly reduced during the procedure
> > > of reaping the killed process.
> > >
> > > The test is based on arm64.
> > >
> > > Without the patch:
> > > |--99.57%-- oom_reaper
> > > | |--0.28%-- [hit in function]
> > > | |--73.58%-- unmap_page_range
> > > | | |--8.67%-- [hit in function]
> > > | | |--41.59%-- __pte_offset_map_lock
> > > | | |--29.47%-- folio_remove_rmap_ptes
> > > | | |--16.11%-- tlb_flush_mmu
> > > | | |--1.66%-- folio_mark_accessed
> > > | | |--0.74%-- free_swap_and_cache_nr
> > > | | |--0.69%-- __tlb_remove_folio_pages
> > > | |--19.94%-- tlb_finish_mmu
> > > | |--3.21%-- folio_remove_rmap_ptes
> > > | |--1.16%-- __tlb_remove_folio_pages
> > > | |--1.16%-- folio_mark_accessed
> > > | |--0.36%-- __pte_offset_map_lock
> > >
> > > With the patch:
> > > |--99.53%-- oom_reaper
> > > | |--55.77%-- unmap_page_range
> > > | | |--20.49%-- [hit in function]
> > > | | |--58.30%-- folio_remove_rmap_ptes
> > > | | |--11.48%-- tlb_flush_mmu
> > > | | |--3.33%-- folio_mark_accessed
> > > | | |--2.65%-- __tlb_remove_folio_pages
> > > | | |--1.37%-- _raw_spin_lock
> > > | | |--0.68%-- __mod_lruvec_page_state
> > > | | |--0.51%-- __pte_offset_map_lock
> > > | |--32.21%-- tlb_finish_mmu
> > > | |--6.93%-- folio_remove_rmap_ptes
> > > | |--1.90%-- __tlb_remove_folio_pages
> > > | |--1.55%-- folio_mark_accessed
> > > | |--0.69%-- __pte_offset_map_lock
> >
> > I do not object to the patch but this profile is not telling much really
> > as already pointed out in prior versions as we do not know the base
> > those percentages are from. It would be really much more helpful to
> > measure the elapse time for the oom_repaer and exit_mmap to see those
> > gains.
>
> I got it. I will reference the perf report like this [1] in the changelog.
> link : https://lore.kernel.org/all/20250908121503.20960-1-zhongjinji@honor.com/ [1]

Yes, this is much more informative. I do not think we need the full
report in the changelog though. I would just add your summary
Summary of measurements (ms):
+---------------------------------------------------------------+
| Category | Applying patch | Without patch|
+-------------------------------+---------------+--------------+
| Total running time | 132.6 | 167.1 |
| (exit_mmap + reaper work) | 72.4 + 60.2 | 90.7 + 76.4 |
+-------------------------------+---------------+--------------+
| Time waiting for pte spinlock | 1.0 | 33.1 |
| (exit_mmap + reaper work) | 0.4 + 0.6 | 10.0 + 23.1 |
+-------------------------------+---------------+--------------+
| folio_remove_rmap_ptes time | 42.0 | 41.3 |
| (exit_mmap + reaper work) | 18.4 + 23.6 | 22.4 + 18.9 |
+---------------------------------------------------------------+

and referenced the full report by the link.

Thanks!

--
Michal Hocko
SUSE Labs