David Rientjes wrote: > I'm not sure why you are proposing adding both of these in the same patch; > they have very different usecases and semantics. Because both of these are for tuning the OOM killer. > > oomkiller_holdoff_ms, as indicated by the changelog, seems to be > correcting some deficiency in the oom reaper. It is not deficiency in the OOM reaper but deficiency in the OOM killer or in the page allocator. > I haven't reviewed that, > but it seems like something that wouldn't need to be fixed with a > timeout-based solution. The problem is that it takes some amount of time to return memory to freelist after memory was reclaimed. Unless we add a callback mechanism for notifying that the memory used by TIF_MEMDIE task was reclaimed and returned to freelist, there is no means to fix this problem. > We either know if we have completed oom reaping > or we haven't, it is something we should easily be able to figure out and > not require heuristics such as this. > > This does not seem to have anything to do with current upstream code that > does not have the oom reaper since the oom killer clearly has > synchronization through oom_lock and we carefully defer for TIF_MEMDIE > processes and abort for those that have not yet fully exited to free its > memory. If patches are going to be proposed on top of the oom reaper, > please explicitly state that. The OOM reaper is irrelevant. The OOM reaper is merely an accelerator for reclaiming memory earlier than now. > > I believe any such race described in the changelog could be corrected by > deferring the oom killer entirely until the oom reaper has been able to > free memory or the oom victim has fully exited. I haven't reviewed that, > so I can't speak definitively, but I think we should avoid _any_ timeout > based solution if possible and there's no indication this is the only way > to solve such a problem. The OOM killer can not know when the reclaimed memory is returned to freelist (and therefore get_page_from_freelist() might succeed). Currently timeout is the only way to mitigate this problem. > > oomkiller_victim_wait_ms seems to be another manifestation of the same > patch which has been nack'd over and over again. I believe the situation is changing due to introduction of the OOM reaper. > It does not address the > situation where there are no additional eligible processes to kill and we > end up panicking the machine when additional access to memory reserves may > have allowed the victim to exit. Randomly killing additional processes > makes that problem worse since if they cannot exit (which may become more > likely than not if all victims are waiting on a mutex held by an > allocating thread). > > My solution for that has always been to grant allocating threads temporary > access to memory reserves in the hope that the mutex be dropped and the > victim may make forward progress. We have this implemented internally and > I've posted a test module that easily exhibits the problem and how it is > fixed. Those who use panic_on_oom = 1 expect that the system triggers kernel panic rather than stall forever. This is a translation of administrator's wish that "Please press SysRq-c on behalf of me if the memory exhausted. In that way, I don't need to stand by in front of the console twenty-four seven." Those who use panic_on_oom = 0 expect that the OOM killer solves OOM condition rather than stall forever. This is a translation of administrator's wish that "Please press SysRq-f on behalf of me if the memory exhausted. In that way, I don't need to stand by in front of the console twenty-four seven." However, since the OOM killer never presses SysRq-f again until the OOM victim terminates, this is annoying administrators. Administrator: "I asked you to press SysRq-f on behalf of me. Why did you let the system stalled forever?" The OOM killer: "I did. The system did not recover from OOM condition." Administrator: "Why you don't try pressing SysRq-f again on behalf of me?" The OOM killer: "I am not programmed to do so." Administrator: "You are really inattentive assistant. OK. Here is a patch that programs you to press SysRq-f again on behalf of me." What I want to say to the OOM killer is "Please don't toss the OOM killer's duty away." when the OOM killer answered "I did something with a hope that OOM condition is solved". And MM people are still NACKing administrator's innocent wish. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx"> email@xxxxxxxxx </a>