linux-kernel - Re: [PATCH v1 1/1] mm: Fix OOM killer and proc stats inaccuracy on large many-core systems

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <20260113155541.1da4b93e2acbb2b4f2cda758@linux-foundation.org>
Date: Tue, 13 Jan 2026 15:55:41 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: 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>, Michal Hocko <mhocko@...e.com>, 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, stable@...r.kernel.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 v1 1/1] mm: Fix OOM killer and proc stats inaccuracy on
 large many-core systems

On Tue, 13 Jan 2026 17:16:16 -0500 Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:

> On 2026-01-13 16:46, Andrew Morton wrote:
> > On Tue, 13 Jan 2026 14:47:34 -0500 Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:
> > 
> >> Use the precise, albeit slower, precise RSS counter sums for the OOM
> >> killer task selection and proc statistics. The approximated value is
> >> too imprecise on large many-core systems.
> > 
> > Thanks.
> > 
> > Problem: if I also queue your "mm: Reduce latency of OOM killer task
> > selection" series then this single patch won't get tested, because the
> > larger series erases this patch, yes?
> 
> That's a good point.
> 
> > 
> > Obvious solution: aim this patch at next-merge-window and let's look at
> > the larger series for the next -rc cycle.  Thoughts?
> 
> Yes, that works for me. Does it mean I should re-submit the hpcc
> series after the next merge window closes, or do you keep a queue of
> stuff waiting for the next -rc cycle somewhere ?

I do keep such a queue, but I rarely use it - things go stale quickly. 
So a fresh version would be best please.

> >> Note that commit 82241a83cd15 ("mm: fix the inaccurate memory statistics
> >> issue for users") introduced get_mm_counter_sum() for precise proc
> >> memory status queries for _some_ proc files. This change renames
> >> get_mm_counter_sum() to get_mm_counter(), thus moving the rest of the
> >> proc files to the precise sum.
> > 
> > Please confirm - switching /proc functions from get_mm_counter_sum() to
> > get_mm_counter_sum() doesn't actually change anything, right?  It would
> > be concerning to add possible overhead to things like task_statm().
> 
> The approach proposed by this patch is to switch all proc ABIs which
> query RSS to the precise sum to eliminate any discrepancy caused by too
> imprecise approximate sums. It's a big hammer, and it can slow down
> those proc interfaces, including task_statm().

Oh, so I misunderstood.

> Is it an issue ?

Well it might be - there are a lot of users out there and they do the
weirdest stuff.

> The hpcc series introduces an approximation which provides accuracy
> limits on the approximation that make the result is still somewhat
> meaninful on large many core systems.

Can we leave the non-oom related parts of procfs as-is for now, then
migrate them over to hpcc when that is available?  Safer that way.

> The overall approach here would be to move back those proc interfaces
> which care about low overhead to the hpcc approximate sum when it lands
> upstream. But in order to learn that, we need to know which proc
> interface files are performance-sensitive. How can we get that data ?

Gee.  Wait for the unhappy emails :(

People do sometimes search all-of-open-source for API changes, but that
doesn't cover in-house things, and tools which whack away at /proc
files are often in-house-only.