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.