On Wed 27-04-16 19:43:08, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Mon 25-04-16 11:55:08, Michal Hocko wrote: > > > On Sun 24-04-16 23:19:03, Tetsuo Handa wrote: > > > > Michal Hocko wrote: > > > > > I have seen that patch. I didn't get to review it properly yet as I am > > > > > still travelling. From a quick view I think it is conflating two things > > > > > together. I could see arguments for the panic part but I do not consider > > > > > the move-to-kill-another timeout as justified. I would have to see a > > > > > clear indication this is actually useful for real life usecases. > > > > > > > > You admit that it is possible that the TIF_MEMDIE thread is blocked at > > > > unkillable wait (due to memory allocation requests by somebody else) but > > > > the OOM reaper cannot reap the victim's memory (due to holding the mmap_sem > > > > for write), don't you? > > > > > > I have never said this to be impossible. > > > > And just to clarify. I consider unkillable sleep while holding mmap_sem > > for write to be a _bug_ which should be fixed rather than worked around > > by some timeout based heuristics. > > Excuse me, but I think that it is difficult to fix. > Since currently it is legal to block kswapd from memory reclaim paths > ( http://lkml.kernel.org/r/20160211225929.GU14668@dastard ) and there > are allocation requests with mmap_sem held for write, you will need to > make memory reclaim paths killable. (I wish memory reclaim paths being > completely killable because fatal_signal_pending(current) check done in > throttle_direct_reclaim() is racy.) Be it difficult or not it is something that should be fixed. -- Michal Hocko SUSE Labs -- 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>