linux-kernel - Re: [PATCH v2 20/23] sched: psi: implement bpf

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: <aQEM7LXpZdOpsgvU@slm.duckdns.org>
Date: Tue, 28 Oct 2025 08:35:24 -1000
From: Tejun Heo <tj@...nel.org>
To: Roman Gushchin <roman.gushchin@...ux.dev>
Cc: Andrew Morton <akpm@...ux-foundation.org>, linux-kernel@...r.kernel.org,
	Alexei Starovoitov <ast@...nel.org>,
	Suren Baghdasaryan <surenb@...gle.com>,
	Michal Hocko <mhocko@...nel.org>,
	Shakeel Butt <shakeel.butt@...ux.dev>,
	Johannes Weiner <hannes@...xchg.org>,
	Andrii Nakryiko <andrii@...nel.org>,
	JP Kobryn <inwardvessel@...il.com>, linux-mm@...ck.org,
	cgroups@...r.kernel.org, bpf@...r.kernel.org,
	Martin KaFai Lau <martin.lau@...nel.org>,
	Song Liu <song@...nel.org>,
	Kumar Kartikeya Dwivedi <memxor@...il.com>
Subject: Re: [PATCH v2 20/23] sched: psi: implement bpf_psi struct ops

Hello,

On Tue, Oct 28, 2025 at 11:29:31AM -0700, Roman Gushchin wrote:
> > Here, too, I wonder whether it's necessary to build a hard-coded
> > infrastructure to hook into PSI's triggers. psi_avgs_work() is what triggers
> > these events and it's not that hot. Wouldn't a fexit attachment to that
> > function that reads the updated values be enough? We can also easily add a
> > TP there if a more structured access is desirable.
> 
> Idk, it would require re-implementing parts of the kernel PSI trigger code
> in BPF, without clear benefits.
> 
> Handling PSI in BPF might be quite useful outside of the OOM handling,
> e.g. it can be used for scheduling decisions, networking throttling,
> memory tiering, etc. So maybe I'm biased (and I'm obviously am here), but
> I'm not too concerned about adding infrastructure which won't be used.
> 
> But I understand your point. I personally feel that the added complexity of
> the infrastructure makes writing and maintaining BPF PSI programs
> simpler, but I'm open to other opinions here.

Yeah, I mean, I'm not necessarily against adding infrastructure if the need
is justified - ie. it enables new things which isn't reasonably feasible
otherwise. However, it's also a good idea to start small, iterate and build
up. It's always easier to add new things than to remove stuff which is
already out there. Wouldn't it make more sense to add the minimum mechanism,
see how things develop and add what's identified as missing in the process?

Thanks.

-- 
tejun