On Tue 16-02-21 13:53:12, David Rientjes wrote: > On Tue, 16 Feb 2021, Michal Hocko wrote: [...] > > Overall, I am not really happy about this feature even when above is > > fixed, but let's hear more the actual problem first. > > Shouldn't this behavior be possible as an oomd plugin instead, perhaps > triggered by psi? I'm not sure if oomd is intended only to kill something > (oomkilld? lol) or if it can be made to do sysadmin level behavior, such > as shrinking the hugetlb pool, to solve the oom condition. It should be under control of an admin who knows what the pool is preallocated for and whether a decrease (e.g. a temporal one) is tolerable. > If so, it seems like we want to do this at the absolute last minute. In > other words, reclaim has failed to free memory by other means so we would > like to shrink the hugetlb pool. (It's the reason why it's implemented as > a predecessor to oom as opposed to part of reclaim in general.) > > Do we have the ability to suppress the oom killer until oomd has a chance > to react in this scenario? We don't and I do not think we want to bind the kernel oom behavior to any userspace process. We have extensively discussed things like this in the past IIRC. -- Michal Hocko SUSE Labs
