On Fri, Jul 28, 2023 at 10:06:38AM +0200, Michal Hocko wrote: > On Thu 27-07-23 21:30:01, Roman Gushchin wrote: > > On Thu, Jul 27, 2023 at 10:15:16AM +0200, Michal Hocko wrote: > > > On Thu 27-07-23 15:36:27, Chuyi Zhou wrote: > > > > This patchset tries to add a new bpf prog type and use it to select > > > > a victim memcg when global OOM is invoked. The mainly motivation is > > > > the need to customizable OOM victim selection functionality so that > > > > we can protect more important app from OOM killer. > > > > > > This is rather modest to give an idea how the whole thing is supposed to > > > work. I have looked through patches very quickly but there is no overall > > > design described anywhere either. > > > > > > Please could you give us a high level design description and reasoning > > > why certain decisions have been made? e.g. why is this limited to the > > > global oom sitation, why is the BPF program forced to operate on memcgs > > > as entities etc... > > > Also it would be very helpful to call out limitations of the BPF > > > program, if there are any. > > > > One thing I realized recently: we don't have to make a victim selection > > during the OOM, we [almost always] can do it in advance. > > > > Kernel OOM's must guarantee the forward progress under heavy memory pressure > > and it creates a lot of limitations on what can and what can't be done in > > these circumstances. > > > > But in practice most policies except maybe those which aim to catch very fast > > memory spikes rely on things which are fairly static: a logical importance of > > several workloads in comparison to some other workloads, "age", memory footprint > > etc. > > > > So I wonder if the right path is to create a kernel interface which allows > > to define a OOM victim (maybe several victims, also depending on if it's > > a global or a memcg oom) and update it periodically from an userspace. > > We already have that interface. Just echo OOM_SCORE_ADJ_MAX to any tasks > that are to be killed with a priority... > Not a great interface but still something available. > > > In fact, the second part is already implemented by tools like oomd, systemd-oomd etc. > > Someone might say that the first part is also implemented by the oom_score > > interface, but I don't think it's an example of a convenient interface. > > It's also not a memcg-level interface. > > What do you mean by not memcg-level interface? What kind of interface > would you propose instead? Something like memory.oom.priority, which is 0 by default, but if set to 1, the memory cgroup is considered a good oom victim. Idk if we need priorities or just fine with a binary thing. Under oom conditions the kernel can look if we have a pre-selected oom target and if not fallback to the current behavior. Thanks!
