From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from m6.gw.fujitsu.co.jp ([10.0.50.76]) by fgwmail6.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id m9T2ctsh011952 for (envelope-from kamezawa.hiroyu@jp.fujitsu.com); Wed, 29 Oct 2008 11:38:55 +0900 Received: from smail (m6 [127.0.0.1]) by outgoing.m6.gw.fujitsu.co.jp (Postfix) with ESMTP id B641253C161 for ; Wed, 29 Oct 2008 11:38:55 +0900 (JST) Received: from s7.gw.fujitsu.co.jp (s7.gw.fujitsu.co.jp [10.0.50.97]) by m6.gw.fujitsu.co.jp (Postfix) with ESMTP id 8F30D240060 for ; Wed, 29 Oct 2008 11:38:55 +0900 (JST) Received: from s7.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s7.gw.fujitsu.co.jp (Postfix) with ESMTP id 76FAE1DB803F for ; Wed, 29 Oct 2008 11:38:55 +0900 (JST) Received: from m105.s.css.fujitsu.com (m105.s.css.fujitsu.com [10.249.87.105]) by s7.gw.fujitsu.co.jp (Postfix) with ESMTP id 3740C1DB8037 for ; Wed, 29 Oct 2008 11:38:55 +0900 (JST) Date: Wed, 29 Oct 2008 11:38:26 +0900 From: KAMEZAWA Hiroyuki Subject: [discuss][memcg] oom-kill extension Message-Id: <20081029113826.cc773e21.kamezawa.hiroyu@jp.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: "linux-mm@kvack.org" Cc: "balbir@linux.vnet.ibm.com" , "menage@google.com" List-ID: Under memory resource controller(memcg), oom-killer can be invoked when it reaches limit and no memory can be reclaimed. In general, not under memcg, oom-kill(or panic) is an only chance to recover the system because there is no available memory. But when oom occurs under memcg, it just reaches limit and it seems we can do something else. Does anyone have plan to enhance oom-kill ? What I can think of now is - add an notifier to user-land. - receiver of notify should work in another cgroup. - automatically extend the limit as emergency - trigger fail-over process. - automatically create a precise report of OOM. - record snapshot of 'ps -elf' and so on of memcg which triggers oom. - freeze processes under cgroup. - maybe freezer cgroup should be mounted at the same time. - can we add memcg-oom-freezing-point in somewhere we can sleep ? Is there a chance to add oom_notifier to memcg ? (netlink ?) But the real problem is that what we can do in the kernel is limited and we need proper userland, anyway ;) Thanks, -Kame -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sd0109e.au.ibm.com (d23rh905.au.ibm.com [202.81.18.225]) by ausmtp04.au.ibm.com (8.13.8/8.13.8) with ESMTP id m9T4NDnq122072 for ; Wed, 29 Oct 2008 15:23:14 +1100 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by sd0109e.au.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m9T48M4f216440 for ; Wed, 29 Oct 2008 15:08:25 +1100 Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m9T48M6c023019 for ; Wed, 29 Oct 2008 15:08:22 +1100 Message-ID: <4907E1B4.6000406@linux.vnet.ibm.com> Date: Wed, 29 Oct 2008 09:38:20 +0530 From: Balbir Singh Reply-To: balbir@linux.vnet.ibm.com MIME-Version: 1.0 Subject: Re: [discuss][memcg] oom-kill extension References: <20081029113826.cc773e21.kamezawa.hiroyu@jp.fujitsu.com> In-Reply-To: <20081029113826.cc773e21.kamezawa.hiroyu@jp.fujitsu.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: KAMEZAWA Hiroyuki Cc: "linux-mm@kvack.org" , "menage@google.com" List-ID: KAMEZAWA Hiroyuki wrote: > Under memory resource controller(memcg), oom-killer can be invoked when it > reaches limit and no memory can be reclaimed. > > In general, not under memcg, oom-kill(or panic) is an only chance to recover > the system because there is no available memory. But when oom occurs under > memcg, it just reaches limit and it seems we can do something else. > > Does anyone have plan to enhance oom-kill ? > > What I can think of now is > - add an notifier to user-land. > - receiver of notify should work in another cgroup. The discussion at the mini-summit was to notify a FIFO in the cgroup and any application can listen in for events. > - automatically extend the limit as emergency No.. I don't like this > - trigger fail-over process. I had suggested memrlimits for the ability to fail application allocations, but no-one liked the idea. We can still implement overcommit functionality if needed and catch failures at allocation time. > - automatically create a precise report of OOM. > - record snapshot of 'ps -elf' and so on of memcg which triggers oom. > > - freeze processes under cgroup. > - maybe freezer cgroup should be mounted at the same time. > - can we add memcg-oom-freezing-point in somewhere we can sleep ? > > Is there a chance to add oom_notifier to memcg ? (netlink ?) > Yes, we should add the oom-notifier. We already have cgroupstats if you want to make use of it. > But the real problem is that what we can do in the kernel is limited > and we need proper userland, anyway ;) > Agreed. -- Balbir -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from m1.gw.fujitsu.co.jp ([10.0.50.71]) by fgwmail7.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id m9T50fOM032651 for (envelope-from kamezawa.hiroyu@jp.fujitsu.com); Wed, 29 Oct 2008 14:00:41 +0900 Received: from smail (m1 [127.0.0.1]) by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 6006445DE3E for ; Wed, 29 Oct 2008 14:00:41 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91]) by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 32EA845DE38 for ; Wed, 29 Oct 2008 14:00:41 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 1614D1DB8043 for ; Wed, 29 Oct 2008 14:00:41 +0900 (JST) Received: from m106.s.css.fujitsu.com (m106.s.css.fujitsu.com [10.249.87.106]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id BF8631DB8040 for ; Wed, 29 Oct 2008 14:00:40 +0900 (JST) Date: Wed, 29 Oct 2008 14:00:12 +0900 From: KAMEZAWA Hiroyuki Subject: Re: [discuss][memcg] oom-kill extension Message-Id: <20081029140012.fff30bce.kamezawa.hiroyu@jp.fujitsu.com> In-Reply-To: <4907E1B4.6000406@linux.vnet.ibm.com> References: <20081029113826.cc773e21.kamezawa.hiroyu@jp.fujitsu.com> <4907E1B4.6000406@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: balbir@linux.vnet.ibm.com Cc: "linux-mm@kvack.org" , "menage@google.com" List-ID: On Wed, 29 Oct 2008 09:38:20 +0530 Balbir Singh wrote: > KAMEZAWA Hiroyuki wrote: > > Under memory resource controller(memcg), oom-killer can be invoked when it > > reaches limit and no memory can be reclaimed. > > > > In general, not under memcg, oom-kill(or panic) is an only chance to recover > > the system because there is no available memory. But when oom occurs under > > memcg, it just reaches limit and it seems we can do something else. > > > > Does anyone have plan to enhance oom-kill ? > > > > What I can think of now is > > - add an notifier to user-land. > > - receiver of notify should work in another cgroup. > > The discussion at the mini-summit was to notify a FIFO in the cgroup and any > application can listen in for events. > add FIFO rather than netlink or user mode helper ? > > - automatically extend the limit as emergency > > No.. I don't like this > Oh, I should write as "automatically extend the limit as emergency via userland daemon which receives notify" > > - trigger fail-over process. > > I had suggested memrlimits for the ability to fail application allocations, but > no-one liked the idea. We can still implement overcommit functionality if needed > and catch failures at allocation time. > Difficult point of memrlimit is that system engineer cannot guarantee "your application will do proper fail over process when malloc() returns NULL". Important applications have emergency-fail-over method via signal(SIGTERM or some.. (if not killed by SIGKILL.) I wonder adding an "moderate oom kill mode" to memcg and send SIGTERM rather than SIGKILL may help many? applications. (But to do fail over, the apps may use more memory....) > > - automatically create a precise report of OOM. > > - record snapshot of 'ps -elf' and so on of memcg which triggers oom. > > > > - freeze processes under cgroup. > > - maybe freezer cgroup should be mounted at the same time. > > - can we add memcg-oom-freezing-point in somewhere we can sleep ? > > > > Is there a chance to add oom_notifier to memcg ? (netlink ?) > > > > Yes, we should add the oom-notifier. We already have cgroupstats if you want to > make use of it. > ok, look into that. > > But the real problem is that what we can do in the kernel is limited > > and we need proper userland, anyway ;) > > > > Agreed. > Thanks, -Kame -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 28 Oct 2008 22:13:03 -0700 (PDT) From: David Rientjes Subject: Re: [discuss][memcg] oom-kill extension In-Reply-To: <20081029140012.fff30bce.kamezawa.hiroyu@jp.fujitsu.com> Message-ID: References: <20081029113826.cc773e21.kamezawa.hiroyu@jp.fujitsu.com> <4907E1B4.6000406@linux.vnet.ibm.com> <20081029140012.fff30bce.kamezawa.hiroyu@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: KAMEZAWA Hiroyuki Cc: balbir@linux.vnet.ibm.com, "linux-mm@kvack.org" , "menage@google.com" , KOSAKI Motohiro , Marcelo Tosatti List-ID: On Wed, 29 Oct 2008, KAMEZAWA Hiroyuki wrote: > > > Does anyone have plan to enhance oom-kill ? > > > > > > What I can think of now is > > > - add an notifier to user-land. > > > - receiver of notify should work in another cgroup. > > > > The discussion at the mini-summit was to notify a FIFO in the cgroup and any > > application can listen in for events. > > > add FIFO rather than netlink or user mode helper ? > There was a patchset from February that added /dev/mem_notify to warn userspace of low or out of memory conditions: http://marc.info/?l=linux-kernel&m=120257050719077 http://marc.info/?l=linux-kernel&m=120257050719087 http://marc.info/?l=linux-kernel&m=120257062719234 http://marc.info/?l=linux-kernel&m=120257071219327 http://marc.info/?l=linux-kernel&m=120257071319334 http://marc.info/?l=linux-kernel&m=120257080919488 http://marc.info/?l=linux-kernel&m=120257081019497 http://marc.info/?l=linux-kernel&m=120257096219705 http://marc.info/?l=linux-kernel&m=120257096319717 Perhaps this idea can simply be reworked for the memory controller or standalone cgroup? -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from m5.gw.fujitsu.co.jp ([10.0.50.75]) by fgwmail5.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id m9T5TRc6031388 for (envelope-from kamezawa.hiroyu@jp.fujitsu.com); Wed, 29 Oct 2008 14:29:29 +0900 Received: from smail (m5 [127.0.0.1]) by outgoing.m5.gw.fujitsu.co.jp (Postfix) with ESMTP id 5CBAA2AC027 for ; Wed, 29 Oct 2008 14:29:27 +0900 (JST) Received: from s4.gw.fujitsu.co.jp (s4.gw.fujitsu.co.jp [10.0.50.94]) by m5.gw.fujitsu.co.jp (Postfix) with ESMTP id 33FDA12C045 for ; Wed, 29 Oct 2008 14:29:27 +0900 (JST) Received: from s4.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id 10DAE1DB803B for ; Wed, 29 Oct 2008 14:29:27 +0900 (JST) Received: from m108.s.css.fujitsu.com (m108.s.css.fujitsu.com [10.249.87.108]) by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id 9BE481DB8044 for ; Wed, 29 Oct 2008 14:29:26 +0900 (JST) Date: Wed, 29 Oct 2008 14:28:58 +0900 From: KAMEZAWA Hiroyuki Subject: Re: [discuss][memcg] oom-kill extension Message-Id: <20081029142858.2db54e92.kamezawa.hiroyu@jp.fujitsu.com> In-Reply-To: References: <20081029113826.cc773e21.kamezawa.hiroyu@jp.fujitsu.com> <4907E1B4.6000406@linux.vnet.ibm.com> <20081029140012.fff30bce.kamezawa.hiroyu@jp.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: David Rientjes Cc: balbir@linux.vnet.ibm.com, "linux-mm@kvack.org" , "menage@google.com" , KOSAKI Motohiro , Marcelo Tosatti List-ID: On Tue, 28 Oct 2008 22:13:03 -0700 (PDT) David Rientjes wrote: > > There was a patchset from February that added /dev/mem_notify to warn > userspace of low or out of memory conditions: > > http://marc.info/?l=linux-kernel&m=120257050719077 > http://marc.info/?l=linux-kernel&m=120257050719087 > http://marc.info/?l=linux-kernel&m=120257062719234 > http://marc.info/?l=linux-kernel&m=120257071219327 > http://marc.info/?l=linux-kernel&m=120257071319334 > http://marc.info/?l=linux-kernel&m=120257080919488 > http://marc.info/?l=linux-kernel&m=120257081019497 > http://marc.info/?l=linux-kernel&m=120257096219705 > http://marc.info/?l=linux-kernel&m=120257096319717 > > Perhaps this idea can simply be reworked for the memory controller or > standalone cgroup? > I know and like that. The concept of mem_notify is notifing shortage of memory by watching page reclaimation. But the situation/usage/purpose is a bit different from oom-killer. (oom-kill is the final stage to recover memory...) To implement mem_notify in memcg's context, my idea is - support followings. => account swap (now going on) => show usage of swap => "reduce memory usage" interface (to decrease noise from usage of file cache) In usual systems, we watche"amount of swap". In swapless systems, watches the amount of anonymous/locked memory under memcg. Or "measure how much time we'll take to reduce memory usage to some level" maybe it's interresting that we can add multi-purpose notifier to memcg. for example, - triggered when anonymous memory is over 95% of limits - triggered when swap occurs. (But can be done by user-land daemon...Hmm?) Thanks, -Kame -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from zps36.corp.google.com (zps36.corp.google.com [172.25.146.36]) by smtp-out.google.com with ESMTP id m9T5ZNNr028290 for ; Wed, 29 Oct 2008 05:35:24 GMT Received: from rv-out-0708.google.com (rvfb17.prod.google.com [10.140.179.17]) by zps36.corp.google.com with ESMTP id m9T5ZMqi015725 for ; Tue, 28 Oct 2008 22:35:22 -0700 Received: by rv-out-0708.google.com with SMTP id b17so3073935rvf.36 for ; Tue, 28 Oct 2008 22:35:21 -0700 (PDT) Message-ID: <6599ad830810282235w5ad7ff7cx4f8be4e1f58933a5@mail.gmail.com> Date: Tue, 28 Oct 2008 22:35:21 -0700 From: "Paul Menage" Subject: Re: [discuss][memcg] oom-kill extension In-Reply-To: <20081029113826.cc773e21.kamezawa.hiroyu@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081029113826.cc773e21.kamezawa.hiroyu@jp.fujitsu.com> Sender: owner-linux-mm@kvack.org Return-Path: To: KAMEZAWA Hiroyuki Cc: "linux-mm@kvack.org" , "balbir@linux.vnet.ibm.com" List-ID: On Tue, Oct 28, 2008 at 7:38 PM, KAMEZAWA Hiroyuki wrote: > Under memory resource controller(memcg), oom-killer can be invoked when it > reaches limit and no memory can be reclaimed. > > In general, not under memcg, oom-kill(or panic) is an only chance to recover > the system because there is no available memory. But when oom occurs under > memcg, it just reaches limit and it seems we can do something else. > > Does anyone have plan to enhance oom-kill ? We have an in-house implementation of a per-cgroup OOM handler that we've just ported from cpusets to cgroups. We were considering sending the patch in as a starting point for discussions - it's a bit of a kludge as it is. It's a standalone subsystem that can work with either the memory cgroup or with cpusets (where memory is constrained by numa nodes). The features are: - an oom.delay file that controls how long a thread will pause in the OOM killer waiting for a response from userspace (in milliseconds) - an oom.await file that a userspace handler can write a timeout value to, and be awoken either when a process in that cgroup enters the OOM killer, or the timeout expires. If a userspace thread catches and handles the OOM, the OOMing thread doesn't trigger a kill, but returns to alloc_pages to try again; alternatively userspace can cause the OOM killer to go ahead as normal. We've found it works pretty successfully as a last-ditch notification to a daemon waiting in a system cgroup which can then expand the memory limits of the failing cgroup if necessary (potentially killing off processes from some other cgroup first if necessary to free up more memory). I'll try to get someone to send in the patch. Paul -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from m4.gw.fujitsu.co.jp ([10.0.50.74]) by fgwmail6.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id m9T5k8LO028388 for (envelope-from kamezawa.hiroyu@jp.fujitsu.com); Wed, 29 Oct 2008 14:46:08 +0900 Received: from smail (m4 [127.0.0.1]) by outgoing.m4.gw.fujitsu.co.jp (Postfix) with ESMTP id 702492AC026 for ; Wed, 29 Oct 2008 14:46:08 +0900 (JST) Received: from s7.gw.fujitsu.co.jp (s7.gw.fujitsu.co.jp [10.0.50.97]) by m4.gw.fujitsu.co.jp (Postfix) with ESMTP id 3C12C12C045 for ; Wed, 29 Oct 2008 14:46:08 +0900 (JST) Received: from s7.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s7.gw.fujitsu.co.jp (Postfix) with ESMTP id 242111DB803E for ; Wed, 29 Oct 2008 14:46:08 +0900 (JST) Received: from m108.s.css.fujitsu.com (m108.s.css.fujitsu.com [10.249.87.108]) by s7.gw.fujitsu.co.jp (Postfix) with ESMTP id C15F11DB803A for ; Wed, 29 Oct 2008 14:46:07 +0900 (JST) Date: Wed, 29 Oct 2008 14:45:39 +0900 From: KAMEZAWA Hiroyuki Subject: Re: [discuss][memcg] oom-kill extension Message-Id: <20081029144539.b6c96cb8.kamezawa.hiroyu@jp.fujitsu.com> In-Reply-To: <6599ad830810282235w5ad7ff7cx4f8be4e1f58933a5@mail.gmail.com> References: <20081029113826.cc773e21.kamezawa.hiroyu@jp.fujitsu.com> <6599ad830810282235w5ad7ff7cx4f8be4e1f58933a5@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Paul Menage Cc: "linux-mm@kvack.org" , "balbir@linux.vnet.ibm.com" List-ID: On Tue, 28 Oct 2008 22:35:21 -0700 "Paul Menage" wrote: > On Tue, Oct 28, 2008 at 7:38 PM, KAMEZAWA Hiroyuki > wrote: > > Under memory resource controller(memcg), oom-killer can be invoked when it > > reaches limit and no memory can be reclaimed. > > > > In general, not under memcg, oom-kill(or panic) is an only chance to recover > > the system because there is no available memory. But when oom occurs under > > memcg, it just reaches limit and it seems we can do something else. > > > > Does anyone have plan to enhance oom-kill ? > > We have an in-house implementation of a per-cgroup OOM handler that > we've just ported from cpusets to cgroups. We were considering sending > the patch in as a starting point for discussions - it's a bit of a > kludge as it is. > Sounds interesting. (but I don't ask details now.) > It's a standalone subsystem that can work with either the memory > cgroup or with cpusets (where memory is constrained by numa nodes). > The features are: > > - an oom.delay file that controls how long a thread will pause in the > OOM killer waiting for a response from userspace (in milliseconds) > > - an oom.await file that a userspace handler can write a timeout value > to, and be awoken either when a process in that cgroup enters the OOM > killer, or the timeout expires. > > If a userspace thread catches and handles the OOM, the OOMing thread > doesn't trigger a kill, but returns to alloc_pages to try again; > alternatively userspace can cause the OOM killer to go ahead as > normal. > the userland can know "bad process" under group ? > We've found it works pretty successfully as a last-ditch notification > to a daemon waiting in a system cgroup which can then expand the > memory limits of the failing cgroup if necessary (potentially killing > off processes from some other cgroup first if necessary to free up > more memory). > This is a good news :) > I'll try to get someone to send in the patch. > O.K. looking forward to see that. Regards, -Kame -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id m9T5nKqG008087 for ; Wed, 29 Oct 2008 05:49:20 GMT Received: from rv-out-0708.google.com (rvfc5.prod.google.com [10.140.180.5]) by wpaz17.hot.corp.google.com with ESMTP id m9T5nIUV007752 for ; Tue, 28 Oct 2008 22:49:18 -0700 Received: by rv-out-0708.google.com with SMTP id c5so2859585rvf.28 for ; Tue, 28 Oct 2008 22:49:18 -0700 (PDT) Message-ID: <6599ad830810282249t1837252bn2d4904faabf81af1@mail.gmail.com> Date: Tue, 28 Oct 2008 22:49:18 -0700 From: "Paul Menage" Subject: Re: [discuss][memcg] oom-kill extension In-Reply-To: <20081029144539.b6c96cb8.kamezawa.hiroyu@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081029113826.cc773e21.kamezawa.hiroyu@jp.fujitsu.com> <6599ad830810282235w5ad7ff7cx4f8be4e1f58933a5@mail.gmail.com> <20081029144539.b6c96cb8.kamezawa.hiroyu@jp.fujitsu.com> Sender: owner-linux-mm@kvack.org Return-Path: To: KAMEZAWA Hiroyuki Cc: "linux-mm@kvack.org" , "balbir@linux.vnet.ibm.com" List-ID: On Tue, Oct 28, 2008 at 10:45 PM, KAMEZAWA Hiroyuki wrote: > the userland can know "bad process" under group ? Not in our current implementation - that's something that might be good to add if we were doing a proper API for inclusion in mainline. Paul -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by wa-out-1112.google.com with SMTP id j37so1954413waf.22 for ; Tue, 28 Oct 2008 23:55:06 -0700 (PDT) Message-ID: <2f11576a0810282355t7a5b5cc1id7442229ded104b1@mail.gmail.com> Date: Wed, 29 Oct 2008 15:55:06 +0900 From: "KOSAKI Motohiro" Subject: Re: [discuss][memcg] oom-kill extension In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081029113826.cc773e21.kamezawa.hiroyu@jp.fujitsu.com> <4907E1B4.6000406@linux.vnet.ibm.com> <20081029140012.fff30bce.kamezawa.hiroyu@jp.fujitsu.com> Sender: owner-linux-mm@kvack.org Return-Path: To: David Rientjes Cc: KAMEZAWA Hiroyuki , balbir@linux.vnet.ibm.com, "linux-mm@kvack.org" , "menage@google.com" , Marcelo Tosatti List-ID: > There was a patchset from February that added /dev/mem_notify to warn > userspace of low or out of memory conditions: > > http://marc.info/?l=linux-kernel&m=120257050719077 > http://marc.info/?l=linux-kernel&m=120257050719087 > http://marc.info/?l=linux-kernel&m=120257062719234 > http://marc.info/?l=linux-kernel&m=120257071219327 > http://marc.info/?l=linux-kernel&m=120257071319334 > http://marc.info/?l=linux-kernel&m=120257080919488 > http://marc.info/?l=linux-kernel&m=120257081019497 > http://marc.info/?l=linux-kernel&m=120257096219705 > http://marc.info/?l=linux-kernel&m=120257096319717 > > Perhaps this idea can simply be reworked for the memory controller or > standalone cgroup? Very sorry. I know my laziness is wrong. I have made split-lru effort give priority more than other awhile. So I'll restart user-land notify effort soon. Paul, I strongly interest to your implementation. Could you post your notify patch? -- 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: email@kvack.org