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

[Andrew Morton <akpm@linux-foundation.org>]

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

> On 2026-01-13 16:46, Andrew Morton wrote:
> > On Tue, 13 Jan 2026 14:47:34 -0500 Mathieu Desnoyers <mathieu.desnoyers@efficios.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.