> 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, 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>