On Tue, 13 Jan 2026 17:16:16 -0500 Mathieu Desnoyers <[email protected]> wrote:
> On 2026-01-13 16:46, Andrew Morton wrote: > > On Tue, 13 Jan 2026 14:47:34 -0500 Mathieu Desnoyers > > <[email protected]> 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.
