linux-kernel - Re: [PATCH v16 3/3] mm: Reduce latency of OOM killer task selection with 2-pass algorithm

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: <aXeommbTq_KNpUZa@tiehlicka>
Date: Mon, 26 Jan 2026 18:47:06 +0100
From: Michal Hocko <mhocko@...e.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, linux-kernel@...r.kernel.org,
	"Paul E. McKenney" <paulmck@...nel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	Dennis Zhou <dennis@...nel.org>, Tejun Heo <tj@...nel.org>,
	Christoph Lameter <cl@...ux.com>, Martin Liu <liumartin@...gle.com>,
	David Rientjes <rientjes@...gle.com>, christian.koenig@....com,
	Shakeel Butt <shakeel.butt@...ux.dev>,
	SeongJae Park <sj@...nel.org>, Johannes Weiner <hannes@...xchg.org>,
	Sweet Tea Dorminy <sweettea-kernel@...miny.me>,
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
	"Liam R . Howlett" <liam.howlett@...cle.com>,
	Mike Rapoport <rppt@...nel.org>,
	Suren Baghdasaryan <surenb@...gle.com>,
	Vlastimil Babka <vbabka@...e.cz>,
	Christian Brauner <brauner@...nel.org>,
	Wei Yang <richard.weiyang@...il.com>,
	David Hildenbrand <david@...hat.com>,
	Miaohe Lin <linmiaohe@...wei.com>,
	Al Viro <viro@...iv.linux.org.uk>, linux-mm@...ck.org,
	linux-trace-kernel@...r.kernel.org, Yu Zhao <yuzhao@...gle.com>,
	Roman Gushchin <roman.gushchin@...ux.dev>,
	Mateusz Guzik <mjguzik@...il.com>,
	Matthew Wilcox <willy@...radead.org>,
	Baolin Wang <baolin.wang@...ux.alibaba.com>,
	Aboorva Devarajan <aboorvad@...ux.ibm.com>
Subject: Re: [PATCH v16 3/3] mm: Reduce latency of OOM killer task selection
 with 2-pass algorithm

On Mon 26-01-26 11:39:33, Mathieu Desnoyers wrote:
> On 2026-01-16 16:55, Michal Hocko wrote:
> > On Wed 14-01-26 14:36:44, Mathieu Desnoyers wrote:
> > > On 2026-01-14 12:06, Michal Hocko wrote:
> > > > On Wed 14-01-26 09:59:15, Mathieu Desnoyers wrote:
> > [...]
> > Thanks to those clarifications
> > > > My overall impression is that the implementation is really involved and
> > > > at this moment I do not really see a big benefit of all the complexity.
> > > 
> > > Note that we can get the proc ABI RSS accuracy improvements with the
> > > previous 2 patches without this 2-pass algo. Do you see more value in
> > > the RSS accuracy improvements than in the oom killer latency reduction ?
> > 
> > Yes, TBH I do not see oom latency as a big problem. As already mention
> > this is a slow path and we are not talking about a huge latency anyway.
> > proc numbers are much more sensitive to latency as they are regularly
> > read by user space tools and accuracy for those matters as well (being
> > off by 100s MB or GBs is simply making those numbers completely bogus).
> 
> It makes sense.
> 
> > > > It would help to explicitly mention what is the the overall imprecision
> > > > of the oom victim selection with the new data structure (maybe this is
> > > > good enough[*]). What if we go with exact precision with the new data
> > > > structure comparing to the original pcp counters.
> > > 
> > > Do you mean comparing using approximate sums with the new data
> > > structure (which has a bounded accuracy of O(nr_cpus*log(nr_cpus)))
> > > compared to the old data structure which had an inaccuracy of
> > > O(nr_cpus^2) ? So if the inaccuracy provided by the new data structure
> > > is good enough for OOM task selection, we could go from precise sum
> > > back to an approximation and just use that with the new data
> > > structure.
> > 
> > Exactly!
> OK, so based on your feedback, I plan to remove this 2-pass algo
> from the series, and simply keep using the precise sum for the OOM
> killer. If people complain about its latency, then we can eventually
> use the approximation provided by the hierarchical counters. But let's
> wait until someone asks for it rather than add this complexity when
> there is no need.
> 
> The hierarchical counters are still useful as they increase the
> accuracy of approximations exported through /proc.
> 
> How does that sound ?

Works for me.

Thanks!
-- 
Michal Hocko
SUSE Labs