Re: [REPOST] [PATCH 2/2] mm,oom: Reverse the order of setting TIF_MEMDIE and sending SIGKILL.

[Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>]

Michal Hocko wrote:
> > > The code would be easier then and the race window much smaller. If we
> > > really needed to prevent from preemption then preempt_{enable,disable}
> > > aournd the whole task_lock region + do_send_sig_info would be still
> > > easier to follow than re-taking task_lock.
> > 
> > What's wrong with re-taking task_lock? It seems to me that re-taking
> > task_lock is more straightforward and easier to follow.
> 
> I dunno it looks more awkward to me. You have to re-check the victim->mm
> after retaking the lock because situation might have changed while the
> lock was dropped. If the mark_oom_victim & do_send_sig_info are in the
> same preempt region then nothing like that is needed. But this is
> probably a matter of taste. I find the above more readable but let's see
> what others think.

Disabling preemption does not guarantee that the race window is small enough.

If we set TIF_MEMDIE before sending SIGKILL, long interrupts (an extreme
example is SysRq-t from keyboard which would last many seconds) can step
between. We will spend some percent (the worst case is 100 percent) of memory
reserves for allocations which are not needed for termination.

If we send SIGKILL before settting TIF_MEMDIE, we will spend 0 percent of
memory reserves for allocations which are not needed for termination.

Memory reserves are limited, and thus we don't want to waste some pages.

--
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>