[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a3hgvhvix2ulzfof6d23f7kzk5clsnea3grmd2wowjyhjwuiyn@ymzvkqf7gcsc>
Date: Thu, 4 Sep 2025 22:12:48 -0400
From: "Liam R. Howlett" <Liam.Howlett@...cle.com>
To: Michal Hocko <mhocko@...e.com>
Cc: zhongjinji <zhongjinji@...or.com>, rientjes@...gle.com,
shakeel.butt@...ux.dev, akpm@...ux-foundation.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, tglx@...utronix.de,
lorenzo.stoakes@...cle.com, surenb@...gle.com, liulu.liu@...or.com,
feng.han@...or.com
Subject: Re: [PATCH v7 2/2] mm/oom_kill: The OOM reaper traverses the VMA
maple tree in reverse order
* Michal Hocko <mhocko@...e.com> [250904 08:21]:
> On Wed 03-09-25 15:02:34, Liam R. Howlett wrote:
> > * Michal Hocko <mhocko@...e.com> [250903 08:58]:
> > > On Wed 03-09-25 17:27:29, zhongjinji wrote:
> [...]
> > mmu_notifier_release(mm) is called early in the exit_mmap() path should
> > cause the mmu notifiers to be non-blocking (according to the comment in
> > v6.0 source of exit_mmap [1].
>
> I am not sure I follow you here. How does this relate to the actual
> direction of the address space freeing?
It doesn't relate to the direction of the address freeing, I think it
explains the perf data a bit.
The exit_mmap() would have a decrease in mmu related work while this
thread will have an increase, I think.
If they race, this thread gets virtually nothing while exit does all of
the work. If they don't race then the work is split.
Does that make sense?
Thanks,
Liam
Powered by blists - more mailing lists