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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aMJ619kjFm00c4OP@tiehlicka>
Date: Thu, 11 Sep 2025 09:31:35 +0200
From: Michal Hocko <mhocko@...e.com>
To: zhongjinji <zhongjinji@...or.com>
Cc: akpm@...ux-foundation.org, feng.han@...or.com, lenb@...nel.org,
	liam.howlett@...cle.com, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, linux-pm@...r.kernel.org, liulu.liu@...or.com,
	lorenzo.stoakes@...cle.com, pavel@...nel.org, rafael@...nel.org,
	rientjes@...gle.com, shakeel.butt@...ux.dev, surenb@...gle.com,
	tglx@...utronix.de
Subject: Re: [PATCH v9 2/2] mm/oom_kill: The OOM reaper traverses the VMA
 maple tree in reverse order

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