On Wed 20-04-16 00:07:50, Tetsuo Handa wrote: > 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. sysrq+f can use the oom_reaper kernel thread. -- 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>