linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: CAI Qian <caiqian@redhat.com>,
	avagin@gmail.com, Andrey Vagin <avagin@openvz.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mel Gorman <mel@csn.ul.ie>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Minchan Kim <minchan.kim@gmail.com>,
	Hugh Dickins <hughd@google.com>, Oleg Nesterov <oleg@redhat.com>
Subject: Re: [PATCH 3/4] oom: oom-killer don't use permillage of system-ram internally
Date: Tue, 10 May 2011 16:40:50 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.00.1105101632290.12477@chino.kir.corp.google.com> (raw)
In-Reply-To: <20110510171724.16B3.A69D9226@jp.fujitsu.com>

On Tue, 10 May 2011, KOSAKI Motohiro wrote:

> CAI Qian reported his kernel did hang-up if he ran fork intensive
> workload and then invoke oom-killer.
> 
> The problem is, Current oom calculation uses 0-1000 normalized value
> (The unit is a permillage of system-ram). Its low precision make
> a lot of same oom score. IOW, in his case, all processes have <1
> oom score and internal integral calculation round it to 1. Thus
> oom-killer kill ineligible process. This regression is caused by
> commit a63d83f427 (oom: badness heuristic rewrite).
> 
> The solution is, the internal calculation just use number of pages
> instead of permillage of system-ram. And convert it to permillage
> value at displaying time.
> 
> This patch doesn't change any ABI (included  /proc/<pid>/oom_score_adj)
> even though current logic has a lot of my dislike thing.
> 

s/permillage/proportion/

This is unacceptable, it does not allow users to tune oom_score_adj 
appropriately based on the scores exported by /proc/pid/oom_score to 
discount an amount of RAM from a thread's memory usage in systemwide, 
memory controller, cpuset, or mempolicy contexts.  This is only possible 
because the oom score is normalized.

What would be acceptable would be to increase the granularity of the score 
to 10000 or 100000 to differentiate between threads using 0.01% or 0.001% 
of RAM from each other, respectively.  The range of oom_score_adj would 
remain the same, however, and be multiplied by 10 or 100, respectively, 
when factored into the badness score baseline.  I don't believe userspace 
cares to differentiate between more than 0.1% of available memory.

The other issue that this patch addresses is the bonus given to root 
processes.  I agree that if a root process is using 4% of RAM that it 
should not be equal to all other threads using 1%.  I do believe that a 
root process using 60% of RAM should be equal priority to a thread using 
57%, however.  Perhaps a compromise would be to give root processes a 
bonus of 1% for every 30% of RAM they consume?

--
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>

  reply	other threads:[~2011-05-11  0:02 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-05 11:44 [PATCH] mm: check zone->all_unreclaimable in all_unreclaimable() Andrey Vagin
2011-03-05 15:20 ` Minchan Kim
2011-03-05 15:34   ` Andrew Vagin
2011-03-05 15:53     ` Minchan Kim
2011-03-05 16:41       ` Andrew Vagin
2011-03-05 17:07         ` Minchan Kim
2011-03-07 21:58           ` Andrew Morton
2011-03-07 23:45             ` Minchan Kim
2011-03-09  5:37               ` KAMEZAWA Hiroyuki
2011-03-09  5:43                 ` KAMEZAWA Hiroyuki
2011-03-10  6:58                 ` Minchan Kim
2011-03-10 23:58                   ` KAMEZAWA Hiroyuki
2011-03-11  0:18                     ` Minchan Kim
2011-03-11  6:08                       ` avagin
2011-03-14  1:03                         ` Minchan Kim
2011-03-08  0:44             ` KAMEZAWA Hiroyuki
2011-03-08  3:06               ` KOSAKI Motohiro
2011-03-08 19:02                 ` avagin
2011-03-09  5:52                   ` KAMEZAWA Hiroyuki
2011-03-09  6:17                   ` KOSAKI Motohiro
2011-03-10 14:08                     ` KOSAKI Motohiro
2011-03-08  8:12               ` Andrew Vagin
2011-03-09  6:06                 ` KAMEZAWA Hiroyuki
2011-05-04  1:38     ` CAI Qian
2011-05-09  6:54       ` KOSAKI Motohiro
2011-05-09  8:47         ` CAI Qian
2011-05-09  9:19           ` KOSAKI Motohiro
2011-05-10  8:11             ` OOM Killer don't works at all if the system have >gigabytes memory (was Re: [PATCH] mm: check zone->all_unreclaimable in all_unreclaimable()) KOSAKI Motohiro
2011-05-10  8:14               ` [PATCH 1/4] oom: improve dump_tasks() show items KOSAKI Motohiro
2011-05-10 23:29                 ` David Rientjes
2011-05-13 10:14                   ` KOSAKI Motohiro
2011-05-10  8:15               ` [PATCH 2/4] oom: kill younger process first KOSAKI Motohiro
2011-05-10 23:31                 ` David Rientjes
2011-05-13 10:15                   ` KOSAKI Motohiro
2011-05-11 23:33                 ` Minchan Kim
2011-05-12  0:52                 ` KAMEZAWA Hiroyuki
2011-05-12  1:30                   ` Minchan Kim
2011-05-12  1:53                     ` KAMEZAWA Hiroyuki
2011-05-12  2:23                       ` Minchan Kim
2011-05-12  3:39                         ` KAMEZAWA Hiroyuki
2011-05-12  4:17                           ` Minchan Kim
2011-05-12 14:38                             ` Paul E. McKenney
2011-05-13 10:18                   ` KOSAKI Motohiro
2011-05-10  8:15               ` [PATCH 3/4] oom: oom-killer don't use permillage of system-ram internally KOSAKI Motohiro
2011-05-10 23:40                 ` David Rientjes [this message]
2011-05-13 10:30                   ` KOSAKI Motohiro
2011-05-10  8:16               ` [PATCH 4/4] oom: don't kill random process KOSAKI Motohiro
2011-05-10 23:41                 ` David Rientjes
2011-05-10 23:22               ` OOM Killer don't works at all if the system have >gigabytes memory (was Re: [PATCH] mm: check zone->all_unreclaimable in all_unreclaimable()) David Rientjes
2011-05-11  2:30               ` CAI Qian
2011-05-11 20:34                 ` David Rientjes
2011-05-12  0:13                   ` Minchan Kim
2011-05-12 19:38                     ` David Rientjes
2011-05-13  4:16                       ` Minchan Kim
2011-05-13 11:04                         ` KOSAKI Motohiro
2011-05-16 20:42                           ` David Rientjes
2011-05-13  6:53                   ` CAI Qian
2011-05-16 20:46                     ` David Rientjes

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.1105101632290.12477@chino.kir.corp.google.com \
    --to=rientjes@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=avagin@gmail.com \
    --cc=avagin@openvz.org \
    --cc=caiqian@redhat.com \
    --cc=hughd@google.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=minchan.kim@gmail.com \
    --cc=oleg@redhat.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