Re: [PATCH 3/8] mm,oom: Use list of mm_struct used by OOM victims.

[Oleg Nesterov <oleg@redhat.com>]

On 07/04, Tetsuo Handa wrote:
>
> Oleg Nesterov wrote:
> > >
> > > --- a/kernel/fork.c
> > > +++ b/kernel/fork.c
> > > @@ -722,6 +722,7 @@ static inline void __mmput(struct mm_struct *mm)
> > >  	}
> > >  	if (mm->binfmt)
> > >  		module_put(mm->binfmt->module);
> > > +	exit_oom_mm(mm);
> >
> > Is it strictly necessary? At first glance not. Sooner or later oom_reaper() should
> > find this mm_struct and do exit_oom_mm(). And given that mm->mm_users is already 0
> > the "extra" __oom_reap_vmas() doesn't really hurt.
> >
> > It would be nice to remove exit_oom_mm() from __mmput(); it takes the global spinlock
> > for the very unlikely case, and if we can avoid it here then perhaps we can remove
> > ->oom_mm from mm_struct.
>
> I changed not to take global spinlock from __mmput() unless that mm was used by
> TIF_MEMDIE threads.

This new version doesn't apply on top of 2/8, I can't really understand it...

> But I don't think I can remove oom_mm from mm_struct

I think we can try later. oom_init() can create a small mem-pool or we can even
use GFP_ATOMIC for the start to (try to) alloc

	struct oom_mm {
		struct mm_struct *mm;	// mm to reap
		struct list_head list;	// node in the oom_mm_list
		...
	};

lets discuss this later, but to do this we need to remove exit_oom_mm() from exit_mm().
Although we can probably add another MMF_flag, but I think it would be nice to avoid
exit_oom_mm anyway, if it is possible.

And in any case personally I really hate oom_mm->comm/pid ;) but I think we
can remove it later either way.

> Thus, I think I need to remember task_struct which got TIF_MEMDIE.

Well, this is unfortunate imho. This in fact turns "reap mm" back into "reap task".

> I'd like to wait for Michal to come back...

Yes. imho this series doesn't look bad, but lets wait for Michal.

> +void exit_oom_mm(struct mm_struct *mm)
> +{
> +	/* Nothing to do unless mark_oom_victim() was called with this mm. */
> +	if (!mm->oom_mm.victim)
> +		return;
> +#ifdef CONFIG_MMU
> +	/*
> +	 * OOM reaper will eventually call __exit_oom_mm().
> +	 * Allow oom_has_pending_mm() to ignore this mm.
> +	 */
> +	set_bit(MMF_OOM_REAPED, &mm->flags);

If the caller is exit_mm(), then mm->mm_users == 0 and oom_has_pending_mm()
can check it is zero instead?

So,

> +#else
> +	__exit_oom_mm(mm);
> +#endif

it seems that only CONFIG_MMU=n needs this... Apart from oom_has_pending_mm()
why do we bother to add the victim's mm to oom_mm_list?

Oleg.

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