On 2018/08/20 14:54, Michal Hocko wrote: >>>> Apart from the former is "sequential processing" and "the OOM reaper pays the cost >>>> for reclaiming" while the latter is "parallel (or round-robin) processing" and "the >>>> allocating thread pays the cost for reclaiming", both are timeout based back off >>>> with number of retry attempt with a cap. >>> >>> And it is exactly the who pays the price concern I've already tried to >>> explain that bothers me. >> >> Are you aware that we can fall into situation where nobody can pay the price for >> reclaiming memory? > > I fail to see how this is related to direct vs. kthread oom reaping > though. Unless the kthread is starved by other means then it can always > jump in and handle the situation. I'm saying that concurrent allocators can starve the OOM reaper kernel thread. I don't care if the OOM reaper kernel thread is starved by something other than concurrent allocators, as long as that something is doing useful things. Allocators wait for progress using (almost) busy loop is prone to lockup; they are not doing useful things. But direct OOM reaping allows allocators avoid lockup and do useful things.
