From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: balbir@linux.vnet.ibm.com
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
"menage@google.com" <menage@google.com>
Subject: Re: [discuss][memcg] oom-kill extension
Date: Wed, 29 Oct 2008 14:00:12 +0900 [thread overview]
Message-ID: <20081029140012.fff30bce.kamezawa.hiroyu@jp.fujitsu.com> (raw)
In-Reply-To: <4907E1B4.6000406@linux.vnet.ibm.com>
On Wed, 29 Oct 2008 09:38:20 +0530
Balbir Singh <balbir@linux.vnet.ibm.com> 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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2008-10-29 5:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-29 2:38 KAMEZAWA Hiroyuki
2008-10-29 4:08 ` Balbir Singh
2008-10-29 5:00 ` KAMEZAWA Hiroyuki [this message]
2008-10-29 5:13 ` David Rientjes
2008-10-29 5:28 ` KAMEZAWA Hiroyuki
2008-10-29 6:55 ` KOSAKI Motohiro
2008-10-29 5:35 ` Paul Menage
2008-10-29 5:45 ` KAMEZAWA Hiroyuki
2008-10-29 5:49 ` Paul Menage
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081029140012.fff30bce.kamezawa.hiroyu@jp.fujitsu.com \
--to=kamezawa.hiroyu@jp.fujitsu.com \
--cc=balbir@linux.vnet.ibm.com \
--cc=linux-mm@kvack.org \
--cc=menage@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox