Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753679Ab1CWB1o (ORCPT ); Tue, 22 Mar 2011 21:27:44 -0400 Received: from fgwmail5.fujitsu.co.jp ([192.51.44.35]:37341 "EHLO fgwmail5.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752116Ab1CWB1l (ORCPT ); Tue, 22 Mar 2011 21:27:41 -0400 X-SecurityPolicyCheck-FJ: OK by FujitsuOutboundMailChecker v1.3.1 From: KOSAKI Motohiro To: Minchan Kim Subject: Re: [PATCH 3/5] oom: create oom autogroup Cc: kosaki.motohiro@jp.fujitsu.com, linux-kernel@vger.kernel.org, Andrew Morton , David Rientjes , Linus Torvalds , Rik van Riel , Oleg Nesterov , linux-mm , Andrey Vagin , Hugh Dickins , KAMEZAWA Hiroyuki , Mike Galbraith , "Luis Claudio R. Goncalves" In-Reply-To: References: <20110322200759.B067.A69D9226@jp.fujitsu.com> Message-Id: <20110323102738.1AC2.A69D9226@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Mailer: Becky! ver. 2.56.05 [ja] Date: Wed, 23 Mar 2011 10:27:35 +0900 (JST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2499 Lines: 58 > On Tue, Mar 22, 2011 at 8:08 PM, KOSAKI Motohiro > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/