Message-ID: <0079bc61-5655-4677-a421-1a61f4c52d59@efficios.com>
Date: Mon, 26 Jan 2026 11:39:33 -0500
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To: Michal Hocko <mhocko@...e.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 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 ?

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com

Powered by blists - more mailing lists