On Tue, Mar 08, 2016 at 03:18:59PM +0100, Michal Hocko wrote: > On Tue 08-03-16 20:01:32, Tetsuo Handa wrote: > > Currently, lowmemorykiller (LMK) is using TIF_MEMDIE for two purposes. > > One is to remember processes killed by LMK, and the other is to > > accelerate termination of processes killed by LMK. > > > > But since LMK is invoked as a memory shrinker function, there still > > should be some memory available. It is very likely that memory > > allocations by processes killed by LMK will succeed without using > > ALLOC_NO_WATERMARKS via TIF_MEMDIE. Even if their allocations cannot > > escape from memory allocation loop unless they use ALLOC_NO_WATERMARKS, > > lowmem_deathpending_timeout can guarantee forward progress by choosing > > next victim process. > > > > On the other hand, mark_oom_victim() assumes that it must be called with > > oom_lock held and it must not be called after oom_killer_disable() was > > called. But LMK is calling it without holding oom_lock and checking > > oom_killer_disabled. It is possible that LMK calls mark_oom_victim() > > due to allocation requests by kernel threads after current thread > > returned from oom_killer_disabled(). This will break synchronization > > for PM/suspend. > > > > This patch introduces per a task_struct flag for remembering processes > > killed by LMK, and replaces TIF_MEMDIE with that flag. By applying this > > patch, assumption by mark_oom_victim() becomes true. > > Thanks for looking into this. A separate flag sounds like a better way > to go (assuming that the flags are not scarce which doesn't seem to be > the case here). > > The LMK cannot kill the frozen tasks now but this shouldn't be a big deal > because this is not strictly necessary for the system to move on. We are > not OOM. > > > Signed-off-by: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> > > Cc: Michal Hocko <mhocko@xxxxxxx> > > Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > > Cc: Arve Hjonnevag <arve@xxxxxxxxxxx> > > Cc: Riley Andrews <riandrews@xxxxxxxxxxx> > > Acked-by: Michal Hocko <mhocko@xxxxxxxx> So, any objection for me taking this through the staging tree? thanks, greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
