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 for Android: free password hash cracker in your pocket

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

Message-ID: <aWpfbSJe5vREzzyd@tiehlicka>
Date: Fri, 16 Jan 2026 16:55:25 +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 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 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!

-- 
Michal Hocko
SUSE Labs