On Sun 04-06-23 01:25:42, Yosry Ahmed wrote: [...] > There has been a parallel discussion in the cover letter thread of v4 > [1]. To summarize, at Google, we have been using OOM scores to > describe different job priorities in a more explicit way -- regardless > of memory usage. It is strictly priority-based OOM killing. Ties are > broken based on memory usage. > > We understand that something like memory.oom.protect has an advantage > in the sense that you can skip killing a process if you know that it > won't free enough memory anyway, but for an environment where multiple > jobs of different priorities are running, we find it crucial to be > able to define strict ordering. Some jobs are simply more important > than others, regardless of their memory usage. I do remember that discussion. I am not a great fan of simple priority based interfaces TBH. It sounds as an easy interface but it hits complications as soon as you try to define a proper/sensible hierarchical semantic. I can see how they might work on leaf memcgs with statically assigned priorities but that sounds like a very narrow usecase IMHO. I do not think we can effort a plethora of different OOM selection algorithms implemented in the kernel. Therefore we should really consider a control interface to be as much extensible and in line with the existing interfaces as much as possible. That is why I am really open to the oom protection concept which fits reasonably well to the reclaim protection scheme. After all oom killer is just a very aggressive method of the memory reclaim. On the other hand I can see a need to customizable OOM victim selection functionality. We've been through that discussion on several other occasions and the best thing we could come up with was to allow to plug BPF into the victim selection process and allow to bypass the system default method. No code has ever materialized from those discussions though. Maybe this is the time to revive that idea again? > It would be great if we can arrive at an interface that serves this > use case as well. > > Thanks! > > [1]https://lore.kernel.org/linux-mm/CAJD7tkaQdSTDX0Q7zvvYrA3Y4TcvLdWKnN3yc8VpfWRpUjcYBw@xxxxxxxxxxxxxx/ -- Michal Hocko SUSE Labs
