On Thu 01-12-22 07:49:04, 程垲涛 Chengkaitao Cheng wrote: > At 2022-12-01 07:29:11, "Roman Gushchin" <roman.gushchin@xxxxxxxxx> wrote: [...] > >The problem is that the decision which process(es) to kill or preserve > >is individual to a specific workload (and can be even time-dependent > >for a given workload). > > It is correct to kill a process with high workload, but it may not be the > most appropriate. I think the specific process to kill needs to be decided > by the user. I think it is the original intention of score_adj design. I guess what Roman tries to say here is that there is no obviously _correct_ oom victim candidate. Well, except for a very narrow situation when there is a memory leak that consumes most of the memory over time. But that is really hard to identify by the oom selection algorithm in general. > >So it's really hard to come up with an in-kernel > >mechanism which is at the same time flexible enough to work for the majority > >of users and reliable enough to serve as the last oom resort measure (which > >is the basic goal of the kernel oom killer). > > > Our goal is to find a method that is less intrusive to the existing > mechanisms of the kernel, and find a more reasonable supplement > or alternative to the limitations of score_adj. > > >Previously the consensus was to keep the in-kernel oom killer dumb and reliable > >and implement complex policies in userspace (e.g. systemd-oomd etc). > > > >Is there a reason why such approach can't work in your case? > > I think that as kernel developers, we should try our best to provide > users with simpler and more powerful interfaces. It is clear that the > current oom score mechanism has many limitations. Users need to > do a lot of timed loop detection in order to complete work similar > to the oom score mechanism, or develop a new mechanism just to > skip the imperfect oom score mechanism. This is an inefficient and > forced behavior You are right that it makes sense to address typical usecases in the kernel if that is possible. But oom victim selection is really hard without a deeper understanding of the actual workload. The more clever we try to be the more corner cases we can produce. Please note that this has proven to be the case in the long oom development history. We used to sacrifice child processes over a large process to preserve work or prefer younger processes. Both those strategies led to problems. Memcg protection based mechanism sounds like an interesting idea because it mimics a reclaim protection scheme but I am a bit sceptical it will be practically useful. Most for 2 reasons. a) memory reclaim protection can be dynamically tuned because on reclaim/refault/psi metrics. oom events are rare and mostly a failure situation. This limits any feedback based approach IMHO. b) Hierarchical nature of the protection will make it quite hard to configure properly with predictable outcome. -- Michal Hocko SUSE Labs
