Michal Hocko wrote: > On Mon 18-04-16 20:59:51, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > Here is what should work - I have only compile tested it. I will prepare > > > the proper patch later this week with other oom reaper patches or after > > > I come back from LSF/MM. > > > > Excuse me, but is system_wq suitable for queuing operations which may take > > unpredictable duration to flush? > > > > system_wq is the one used by schedule[_delayed]_work[_on](). > > Multi-CPU multi-threaded. There are users which expect relatively > > short queue flush time. Don't queue works which can run for too > > long. > > An alternative would be using a dedicated WQ with WQ_MEM_RECLAIM which I > am not really sure would be justified considering we are talking about a > highly unlikely event. You do not want to consume resources permanently > for an eventual and not fatal event. Yes, the reason SysRq-f is still not using a dedicated WQ with WQ_MEM_RECLAIM will be the same. > > > We > > haven't guaranteed that SysRq-f can always fire and select a different OOM > > victim, but you proposed always clearing TIF_MEMDIE without thinking the > > possibility of the OOM victim with mmap_sem held for write being stuck at > > unkillable wait. > > > > I wonder about your definition of "robustness". You are almost always missing > > the worst scenario. You are trying to manage OOM without defining default: > > label in a switch statement. I don't think your approach is robust. > > I am trying to be as robust as it is viable. You have to realize we are > in the catastrophic path already and there is simply no deterministic > way out. I know we are talking about the catastrophic situation. Since you insist on deterministic approach, we are struggling so much. If you tolerate http://lkml.kernel.org/r/201604152111.JBD95763.LMFOOHQOtFSFJV@xxxxxxxxxxxxxxxxxxx approach as the fastpath (deterministic but could fail) and http://lkml.kernel.org/r/201604200006.FBG45192.SOHFQJFOOLFMtV@xxxxxxxxxxxxxxxxxxx approach as the slowpath (non-deterministic but never fail), we don't need to use a dedicated WQ with WQ_MEM_RECLAIM for avoiding this mmput() trap and the SysRq-f trap. What a simple answer. ;-) -- 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>