On Wed 29-04-20 09:51:39, Vlastimil Babka wrote: > On 4/28/20 11:48 PM, David Rientjes wrote: > > On Tue, 28 Apr 2020, Vlastimil Babka wrote: > > > > Yes, order-0 reclaim capture is interesting since the issue being reported > > here is userspace going out to lunch because it loops for an unbounded > > amount of time trying to get above a watermark where it's allowed to > > allocate and other consumers are depleting that resource. > > > > We actually prefer to oom kill earlier rather than being put in a > > perpetual state of aggressive reclaim that affects all allocators and the > > unbounded nature of those allocations leads to very poor results for > > everybody. > > Sure. My vague impression is that your (and similar cloud companies) kind of > workloads are designed to maximize machine utilization, and overshooting and > killing something as a result is no big deal. Then you perhaps have more > probability of hitting this state, and on the other hand, even an occasional > premature oom kill is not a big deal? > > My concers are workloads not designed in such a way, where premature oom kill > due to temporary higher reclaim activity together with burst of incoming network > packets will result in e.g. killing an important database. There, the tradeoff > looks different. Completely agreed! The in kernel OOM killer is to deal with situations when memory is desperately depleted without any sign of a forward progress. If there is a reclaimable memory then we are not there yet. If a workload can benefit from early oom killing based on response time then we have facilities to achieve that (e.g. PSI). -- Michal Hocko SUSE Labs
