[Still catching up with older threads. Sorry for the late reply] On Mon 14-08-23 19:25:08, Chuyi Zhou wrote: > Hello, > > 在 2023/8/9 15:53, Michal Hocko 写道: > > On Tue 08-08-23 14:41:17, Roman Gushchin wrote: [...] > > > It would be also nice to come up with some practical examples of bpf programs. > > > What are meaningful scenarios which can be covered with the proposed approach > > > and are not covered now with oom_score_adj. > > > Just like Abel said, the oom_score_adj only adjusts the memory usage-based > decisions, and it's hard to be translated into other semantics. We see that > some userspace oom-killer like oomd has implemented policies based on other > semantics(e.g., memory growth, priority, psi pressure, ect.) which can be > useful in some specific scenario. Sure, I guess we do not really need to discuss that oom_score_adj is not a great fit ;) We want to have practical (read no-toy) oom policies that are useful as a PoC though. > > Agreed here as well. This RFC serves purpose of brainstorming on all of > > this. > > > > There is a fundamental question whether we need BPF for this task in the > > first place. Are there any huge advantages to export the callback and > > allow a kernel module to hook into it? > > If we export the callback to a kernel module and hook into it, > We still have the same problems (e.g., allocating much memory). Just like > Martin saied, at least BPF supports some basic running context and some > unsafe behavior is restricted. I do not follow. Kernel module has access to any existing kernel interfaces without any need to BPF them. So what exactly is the strength of the BPF over kernel module hook? I am pretty sure there are some (many?) but it is really important to be explicit about those before we make any decision. -- Michal Hocko SUSE Labs
