On Tue 21-08-18 07:03:10, Tetsuo Handa wrote: > 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. As long as those allocators are making _some_ progress and they are not preempted themselves. Those might be low priority as well. To make it more fun those high priority might easily preempt those which try to make the direct reaping. And if you really want to achieve at least some fairness there you will quickly grown into a complex scheme. Really our direct reclaim is already quite fragile when it comes to fairness and now you want to extend it to be even more fragile. Really, I think you are not really appreciating what kind of complex beast you are going to create. If we have priority inversion problems during oom then we can always return back to high priority oom reaper. This would be so much simpler. -- Michal Hocko SUSE Labs
