From: <leonid.moiseichuk@nokia.com>
To: rientjes@google.com
Cc: gregkh@suse.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
cesarb@cesarb.net, kamezawa.hiroyu@jp.fujitsu.com,
emunson@mgebm.net, penberg@kernel.org, aarcange@redhat.com,
riel@redhat.com, mel@csn.ul.ie, dima@android.com,
rebecca@android.com, san@google.com, akpm@linux-foundation.org,
vesa.jaaskelainen@nokia.com
Subject: RE: [PATCH 3.2.0-rc1 3/3] Used Memory Meter pseudo-device module
Date: Thu, 12 Jan 2012 08:32:16 +0000 [thread overview]
Message-ID: <84FF21A720B0874AA94B46D76DB9826904556CB7@008-AM1MPN1-003.mgdnok.nokia.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1201111338320.21755@chino.kir.corp.google.com>
> -----Original Message-----
> From: ext David Rientjes [mailto:rientjes@google.com]
> Sent: 11 January, 2012 22:45
> I think you're misunderstanding the proposal; in the case of a global oom
> (that means without memcg) then, by definition, all threads that are
> allocating memory would be frozen and incur the delay at the point they
> would currently call into the oom killer. If your userspace is alive, i.e. the
> application responsible for managing oom killing, then it can wait on
> eventfd(2), wake up, and then send SIGTERM and SIGKILL to the appropriate
> threads based on priority.
>
> So, again, why wouldn't this work for you?
As I wrote the proposed change is not safety belt but looking ahead radar.
If it detects that we are close to wall it starts to alarm and alarm volume is proportional to distance.
In close-to-OOM situations device becomes very slow, which is not good for user. The performance difference depends on code size and storage performance
to trash code pages but even 20% is noticeable. Practically 2x-5x times slowdown was observed.
We can do some actions ahead of time and try to prevent OOM at all like shrink caches in applications, close unused apps etc. If OOM still happened due to
3rd party components or misbehaving software even default OOM killer works good enough if oom_score_adj values are properly set.
Thus, controlling device on wider set of memory situations looks for me more beneficial than trying to recover when situation is bad. And increasing complexity
of recovery mechanism (OOM, Android OOM, OOM with delay), involving user-space into decision-making, makes recovery _potentially_ less predictable.
Best Wishes,
Leonid
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-01-12 8:32 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-04 17:21 [PATCH 3.2.0-rc1 0/3] Used Memory Meter pseudo-device and related changes in MM Leonid Moiseichuk
2012-01-04 17:21 ` [PATCH 3.2.0-rc1 1/3] Making si_swapinfo exportable Leonid Moiseichuk
2012-01-04 17:21 ` [PATCH 3.2.0-rc1 2/3] MM hook for page allocation and release Leonid Moiseichuk
2012-01-04 20:40 ` Pekka Enberg
2012-01-05 6:59 ` KAMEZAWA Hiroyuki
2012-01-05 11:26 ` leonid.moiseichuk
2012-01-05 12:49 ` Pekka Enberg
2012-01-05 15:05 ` Rik van Riel
2012-01-05 15:17 ` leonid.moiseichuk
2012-01-05 15:22 ` Mel Gorman
2012-01-04 17:21 ` [PATCH 3.2.0-rc1 3/3] Used Memory Meter pseudo-device module Leonid Moiseichuk
2012-01-04 19:55 ` Greg KH
2012-01-09 9:58 ` leonid.moiseichuk
2012-01-09 10:09 ` David Rientjes
2012-01-09 10:19 ` leonid.moiseichuk
2012-01-09 20:55 ` David Rientjes
2012-01-11 12:46 ` leonid.moiseichuk
2012-01-11 21:44 ` David Rientjes
2012-01-12 8:32 ` leonid.moiseichuk [this message]
2012-01-12 20:54 ` David Rientjes
2012-01-13 9:34 ` leonid.moiseichuk
2012-01-13 11:06 ` David Rientjes
2012-01-13 11:51 ` leonid.moiseichuk
2012-01-13 21:35 ` David Rientjes
2012-01-04 19:56 ` [PATCH 3.2.0-rc1 0/3] Used Memory Meter pseudo-device and related changes in MM Greg KH
2012-01-04 20:17 ` Rik van Riel
2012-01-04 20:42 ` Pekka Enberg
2012-01-05 23:01 ` David Rientjes
2012-01-05 12:22 ` leonid.moiseichuk
2012-01-05 11:47 ` leonid.moiseichuk
2012-01-05 12:40 ` Pekka Enberg
2012-01-05 13:02 ` leonid.moiseichuk
2012-01-05 14:57 ` Greg KH
2012-01-05 16:13 ` leonid.moiseichuk
2012-01-05 23:10 ` David Rientjes
2012-01-09 8:27 ` leonid.moiseichuk
2012-01-06 0:26 ` KOSAKI Motohiro
2012-01-09 8:49 ` leonid.moiseichuk
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=84FF21A720B0874AA94B46D76DB9826904556CB7@008-AM1MPN1-003.mgdnok.nokia.com \
--to=leonid.moiseichuk@nokia.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=cesarb@cesarb.net \
--cc=dima@android.com \
--cc=emunson@mgebm.net \
--cc=gregkh@suse.de \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=penberg@kernel.org \
--cc=rebecca@android.com \
--cc=riel@redhat.com \
--cc=rientjes@google.com \
--cc=san@google.com \
--cc=vesa.jaaskelainen@nokia.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