Re: [PATCH 3/5] oom: create oom autogroup

[KOSAKI Motohiro]

> On Tue, Mar 22, 2011 at 8:08 PM, KOSAKI Motohiro
> <kosaki.motohiro@xxxxxxxxxxxxxx> wrote:
> > When plenty processes (eg fork bomb) are running, the TIF_MEMDIE task
> > never exit, at least, human feel it's never. therefore kernel become
> > hang-up.
> >
> > "perf sched" tell us a hint.
> >
> > Â------------------------------------------------------------------------------
> > ÂTask         Â|  Runtime ms Â| Average delay ms | Maximum delay ms |
> > Â------------------------------------------------------------------------------
> > Âpython:1754 Â Â Â Â Â | Â Â Â0.197 ms | avg: 1731.727 ms | max: 3433.805 ms |
> > Âpython:1843 Â Â Â Â Â | Â Â Â0.489 ms | avg: 1707.433 ms | max: 3622.955 ms |
> > Âpython:1715 Â Â Â Â Â | Â Â Â0.220 ms | avg: 1707.125 ms | max: 3623.246 ms |
> > Âpython:1818 Â Â Â Â Â | Â Â Â2.127 ms | avg: 1527.331 ms | max: 3622.553 ms |
> > Â...
> > Â...
> >
> > Processes flood makes crazy scheduler delay. and then the victim process
> > can't run enough. Grr. Should we do?
> >
> > Fortunately, we already have anti process flood framework, autogroup!
> > This patch reuse this framework and avoid kernel live lock.
> 
> That's cool idea but I have a concern.
> 
> You remove boosting priority in [2/5] and move victim tasks into autogroup.
> If I understand autogroup right, victim process and threads in the
> process take less schedule chance than now.

Right. Icky cpu-cgroup rt-runtime default enforce me to seek another solution.
Today, I got private mail from Luis and he seems to have another improvement
idea. so, I might drop this patch if his one works fine.

> Could it make unnecessary killing of other tasks?
> I am not sure. Just out of curiosity.

If you are talking about OOM serialization, It isn't. I don't change
OOM serialization stuff. at least for now.
If you are talking about scheduler fairness, both current and this patch
have scheduler unfairness. But that's ok. 1) When OOM situation, scheduling
fairness has been broken already by heavy memory reclaim effort 2) autogroup
mean to change scheduling grouping *automatically*. then, the patch change it
again for exiting memory starvation.

> 
> Thanks for nice work, Kosaki.






--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/