Re: [PATCH v3] mm,oom: speed up select_bad_process() loop.

[Michal Hocko <mhocko@kernel.org>]

On Sat 21-05-16 00:56:26, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > > > > Note that "[PATCH v3] mm,oom: speed up select_bad_process() loop." temporarily
> > > > > broke oom_task_origin(task) case, for oom_select_bad_process() might select
> > > > > a task without mm because oom_badness() which checks for mm != NULL will not be
> > > > > called.
> > > > 
> > > > How can we have oom_task_origin without mm? The flag is set explicitly
> > > > while doing swapoff resp. writing to ksm. We clear the flag before
> > > > exiting.
> > > 
> > > What if oom_task_origin(task) received SIGKILL, but task was unable to run for
> > > very long period (e.g. 30 seconds) due to scheduling priority, and the OOM-reaper
> > > reaped task's mm within a second. Next round of OOM-killer selects the same task
> > > due to oom_task_origin(task) without doing MMF_OOM_REAPED test.
> > 
> > Which is actuall the intended behavior. The whole point of
> > oom_task_origin is to prevent from killing somebody because of
> > potentially memory hungry operation (e.g. swapoff) and rather kill the
> > initiator. 
> 
> Is it guaranteed that try_to_unuse() from swapoff is never blocked on memory
> allocation (e.g. mmput(), wait_on_page_*()) ?

It shouldn't. All the waiting should be killable. If not it is a bug and
should be fixed.
-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>