From: David Rientjes <rientjes@google.com>
To: leonid.moiseichuk@nokia.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: Fri, 13 Jan 2012 03:06:20 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.00.1201130253560.15417@chino.kir.corp.google.com> (raw)
In-Reply-To: <84FF21A720B0874AA94B46D76DB9826904557417@008-AM1MPN1-003.mgdnok.nokia.com>
On Fri, 13 Jan 2012, leonid.moiseichuk@nokia.com wrote:
> > Then it's fundamentally flawed since there's no guarantee that coming with
> > 100MB of the min watermark, for example, means that an oom is imminent
> > and will just result in unnecessary notification to userspace that will cause
> > some action to be taken that may not be necessary. If the setting of these
> > thresholds depends on some pattern that is guaranteed to be along the path
> > to oom for a certain workload, then that will also change depending on VM
> > implementation changes, kernel versions, other applications, etc., and simply
> > is unmaintainable.
>
> Why? That is expected that product tested and tuned properly,
> applications fixed, and at least no apps installed which might consume
> 100 MB in second or two.
I'm trying to make this easy for you, if you haven't noticed. Your memory
threshold, as proposed, will have values that are tied directly to the
implementation of the VM in the kernel when its under memory pressure and
that implementation evolves at a constant rate.
What I'm proposing is limiting the amount of latency that the VM incurs
when under memory pressure, notify userspace, and allow it to react to the
situation until the delay expires. This doesn't require recalibration for
other products or upgraded kernels, it just works all the time.
> Slowdown is natural thing if you have lack of space for code paging, I
> do not see any ways to fix it.
>
mlock() the memory that your userspace monitoring needs to send signals to
applications, whether those signals are handled to free memory internally
or its SIGTERM or SIGKILL.
--
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-13 11:06 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
2012-01-12 20:54 ` David Rientjes
2012-01-13 9:34 ` leonid.moiseichuk
2012-01-13 11:06 ` David Rientjes [this message]
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=alpine.DEB.2.00.1201130253560.15417@chino.kir.corp.google.com \
--to=rientjes@google.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=leonid.moiseichuk@nokia.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=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