linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: Pekka Enberg <penberg@kernel.org>
Cc: Rik van Riel <riel@redhat.com>, linux-mm <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	leonid.moiseichuk@nokia.com, kamezawa.hiroyu@jp.fujitsu.com,
	mel@csn.ul.ie, rientjes@google.com,
	KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ronen Hod <rhod@redhat.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Subject: Re: [RFC 1/3] /dev/low_mem_notify
Date: Wed, 18 Jan 2012 16:49:30 +0900	[thread overview]
Message-ID: <20120118074930.GA18621@barrios-desktop.redhat.com> (raw)
In-Reply-To: <alpine.LFD.2.02.1201180905040.2488@tux.localdomain>

On Wed, Jan 18, 2012 at 09:16:49AM +0200, Pekka Enberg wrote:
> On Wed, 18 Jan 2012, Minchan Kim wrote:
> >I didn't look into your code(will do) but as I read description,
> >still I don't convince we need really some process specific threshold like 99%
> >I think application can know it by polling /proc/meminfo without this mechanism
> >if they really want.
> 
> I'm not sure if we need arbitrary threshold either. However, we need
> to support the following cases:
> 
>   - We're about to swap
> 
>   - We're about to run out of memory
> 
>   - We're about to start OOM killing
> 
> and I don't think your patch solves that. One possibility is to implement:

I think my patch can extend it but your ABI looks good to me than my approach.

> 
>   VMNOTIFY_TYPE_ABOUT_TO_SWAP
>   VMNOTIFY_TYPE_ABOUT_TO_OOM
>   VMNOTIFY_TYPE_ABOUT_TO_OOM_KILL

Yes. We can define some levels.

1. page cache reclaim
2. code page reclaim
3. anonymous page swap out
4. OOM kill.


Application might handle it differenlty by the memory pressure level.

> 
> and maybe rip out support for arbitrary thresholds. Does that more
> reasonable?

Currently, Nokia people seem to want process specific thresholds so 
we might need it.

> 
> As for polling /proc/meminfo, I'd much rather deliver stats as part
> of vmnotify_read() because it's easier to extend the ABI rather than
> adding new fields to /proc/meminfo.

Agree.

> 
> On Wed, 18 Jan 2012, Minchan Kim wrote:
> >I would like to notify when system has a trobule with memory pressure without
> >some process specific threshold. Of course, applicatoin can't expect it.(ie,
> >application can know system memory pressure by /proc/meminfo but it can't know
> >when swapout really happens). Kernel low mem notify have to give such notification
> >to user space, I think.
> 
> It should be simple to add support for VMNOTIFY_TYPE_MEM_PRESSURE
> that uses your hooks.

Indeed.

> 
> 			Pekka

  reply	other threads:[~2012-01-18  7:49 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-17  8:13 [RFC 0/3] low memory notify Minchan Kim
2012-01-17  8:13 ` [RFC 1/3] /dev/low_mem_notify Minchan Kim
2012-01-17  9:27   ` Pekka Enberg
2012-01-17 16:35     ` Rik van Riel
2012-01-17 18:51       ` Pekka Enberg
2012-01-17 19:30         ` Rik van Riel
2012-01-17 19:49           ` Pekka Enberg
2012-01-17 19:54             ` Pekka Enberg
2012-01-17 19:57             ` Pekka Enberg
2012-01-17 23:20         ` Minchan Kim
2012-01-18  7:16           ` Pekka Enberg
2012-01-18  7:49             ` Minchan Kim [this message]
2012-01-18  9:06         ` leonid.moiseichuk
2012-01-18  9:15           ` Pekka Enberg
2012-01-18  9:41             ` leonid.moiseichuk
2012-01-18 10:40               ` Pekka Enberg
2012-01-18 10:44                 ` leonid.moiseichuk
2012-01-18 23:34                   ` Ronen Hod
2012-01-19  7:25                     ` Pekka Enberg
2012-01-19  9:05                       ` Ronen Hod
2012-01-19  9:10                         ` Pekka Enberg
2012-01-19  9:20                           ` Ronen Hod
2012-01-19 10:53                             ` leonid.moiseichuk
2012-01-19 11:07                               ` Pekka Enberg
2012-01-19 11:54                                 ` leonid.moiseichuk
2012-01-19 11:59                                   ` Pekka Enberg
2012-01-19 12:06                                   ` Pekka Enberg
2012-01-24 15:38                               ` Marcelo Tosatti
2012-01-24 16:08                                 ` Ronen Hod
2012-01-24 18:10                                   ` Marcelo Tosatti
2012-01-25  8:52                                     ` Ronen Hod
2012-01-25 10:12                                       ` Marcelo Tosatti
2012-01-25 10:48                                         ` Ronen Hod
2012-01-26 16:17                                           ` Marcelo Tosatti
2012-01-24 16:10                                 ` Pekka Enberg
2012-01-24 18:29                                   ` Marcelo Tosatti
2012-01-25  8:19                                   ` leonid.moiseichuk
2012-01-19  7:34                   ` Pekka Enberg
2012-01-24 16:22             ` Arnd Bergmann
2012-01-18 14:30           ` Rik van Riel
2012-01-18 15:29             ` Pekka Enberg
2012-01-24 15:40         ` Marcelo Tosatti
2012-01-24 16:01           ` Pekka Enberg
2012-01-24 16:25             ` Arnd Bergmann
2012-01-24 18:32               ` Marcelo Tosatti
2012-01-24 21:57         ` Jonathan Corbet
2012-01-17  9:45   ` Pekka Enberg
2012-01-17  8:13 ` [RFC 2/3] vmscan hook Minchan Kim
2012-01-17  8:39   ` KAMEZAWA Hiroyuki
2012-01-17  9:13     ` Minchan Kim
2012-01-17 10:05       ` KAMEZAWA Hiroyuki
2012-01-17 23:08         ` Minchan Kim
2012-01-18  0:18           ` KAMEZAWA Hiroyuki
2012-01-18 14:17             ` Rik van Riel
2012-01-19  2:25               ` KAMEZAWA Hiroyuki
2012-01-19 14:42                 ` Rik van Riel
2012-01-20  0:24                   ` KAMEZAWA Hiroyuki
2012-01-17  8:13 ` [RFC 3/3] test program Minchan Kim
2012-01-17 14:38 ` [RFC 0/3] low memory notify Colin Walters
2012-01-17 15:04   ` Pekka Enberg
2012-01-17 16:44   ` Rik van Riel
2012-01-17 17:16 ` Olof Johansson

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=20120118074930.GA18621@barrios-desktop.redhat.com \
    --to=minchan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kosaki.motohiro@gmail.com \
    --cc=kosaki.motohiro@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=mtosatti@redhat.com \
    --cc=penberg@kernel.org \
    --cc=rhod@redhat.com \
    --cc=riel@redhat.com \
    --cc=rientjes@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;
as well as URLs for NNTP newsgroup(s).