> On Wed, 2 Jun 2010, KOSAKI Motohiro wrote:
>
> > > > @@ -291,9 +309,10 @@ static struct task_struct *select_bad_process(unsigned long *ppoints,
> > > > * Otherwise we could get an easy OOM deadlock.
> > > > */
> > > > if (p->flags & PF_EXITING) {
> > > > - if (p != current)
> > > > + if (p != current) {
> > > > + boost_dying_task_prio(p, mem);
> > > > return ERR_PTR(-1UL);
> > > > -
> > > > + }
> > > > chosen = p;
> > > > *ppoints = ULONG_MAX;
> > > > }
> > >
> > > This has the potential to actually make it harder to free memory if p is
> > > waiting to acquire a writelock on mm->mmap_sem in the exit path while the
> > > thread holding mm->mmap_sem is trying to run.
> >
> > if p is waiting, changing prio have no effect. It continue tol wait to release mmap_sem.
> >
>
> And that can reduce the runtime of the thread holding a writelock on
> mm->mmap_sem, making the exit actually take longer than without the patch
> if its priority is significantly higher, especially on smaller machines.
If p need mmap_sem, p is going to sleep to wait mmap_sem. if p doesn't,
quickly exit is good thing. In other word, task fairness is not our goal
when oom occur.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>