linux-kernel - Re: [RFC PATCH v2] mm: use per-numa-node atomics instead of percpu

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: <CAGudoHF_sD0T9JHSpJyJiBqKd2cO+5jFjvNBpEx4Mp+uK044PQ@mail.gmail.com>
Date: Thu, 3 Apr 2025 18:39:23 +0200
From: Mateusz Guzik <mjguzik@...il.com>
To: Sweet Tea Dorminy <sweettea-kernel@...miny.me>
Cc: Andrew Morton <akpm@...ux-foundation.org>, Steven Rostedt <rostedt@...dmis.org>, 
	Masami Hiramatsu <mhiramat@...nel.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, 
	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 König <christian.koenig@....com>, 
	Shakeel Butt <shakeel.butt@...ux.dev>, Johannes Weiner <hannes@...xchg.org>, 
	Sweet Tea Dorminy <sweettea@...gle.com>, Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, 
	"Liam R . Howlett" <Liam.Howlett@...cle.com>, 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-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org, 
	Yu Zhao <yuzhao@...gle.com>, Roman Gushchin <roman.gushchin@...ux.dev>
Subject: Re: [RFC PATCH v2] mm: use per-numa-node atomics instead of percpu_counters

On Tue, Apr 1, 2025 at 12:36 AM Sweet Tea Dorminy
<sweettea-kernel@...miny.me> wrote:
>
> [Resend as requested as RFC and minus prereq-patch-id junk]
>
> Recently, several internal services had an RSS usage regression as part of a
> kernel upgrade. Previously, they were on a pre-6.2 kernel and were able to
> read RSS statistics in a backup watchdog process to monitor and decide if
> they'd overrun their memory budget. Now, however, a representative service
> with five threads, expected to use about a hundred MB of memory, on a 250-cpu
> machine had memory usage tens of megabytes different from the expected amount
> -- this constituted a significant percentage of inaccuracy, causing the
> watchdog to act.
>
[snip]
> I think the important part is that this improves accuracy; the current
> scheme is difficult to use on many-cored machines. It improves
> performance, but there are tradeoffs; but it tightly bounds the
> inaccuracy so that decisions can actually be reasonably made with the
> resulting numbers.
>

Even disregarding this specific report, a prior patch submission
points a result which is so off that it already constitutes a bug:
https://lwn.net/ml/linux-kernel/20220728204511.56348-1-ryncsn@gmail.com/

So something definitely needs to be done to improve the accuracy. But
that always will be a tradeoff vs update performance.

This brings me to a question: how often does the watchdog thing look
at the stats?

I wonder if it would make sense add another file to proc, similar to
"status", but returning *exact* values. So in particular with percpu
counters it would walk all CPUs on to generate the answer.

Then interested parties would still get an accurate count and not get
in the way, provided they don't relentlessly do it.
-- 
Mateusz Guzik <mjguzik gmail.com>