linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Nick Piggin <npiggin@suse.de>, Oleg Nesterov <oleg@redhat.com>,
	Balbir Singh <balbir@in.ibm.com>,
	linux-mm@kvack.org
Subject: Re: [patch -mm 1/2] oom: badness heuristic rewrite
Date: Mon, 2 Aug 2010 18:50:11 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.00.1008021837370.19184@chino.kir.corp.google.com> (raw)
In-Reply-To: <20100803100815.11d10519.kamezawa.hiroyu@jp.fujitsu.com>

On Tue, 3 Aug 2010, KAMEZAWA Hiroyuki wrote:

> Hmm, then, oom_score shows the values for all limitations in array ?
> 

/proc/pid/oom_score will change if a task's cpuset, memcg, or mempolicy 
attachment changes or its mems, nodes, or limit changes because it's a 
proportion of available memory.  /proc/pid/oom_score_adj stays constant 
such that the oom killing priority of that task relative to other tasks 
sharing the same constraints and competing for the same memory is the 
same.  The point is that it doesn't matter how much memory a task has 
available, but rather what it's priority is with the tasks that compete 
with it for memory.

You could, of course, do some simple arithmetic to write a memory quantity 
to oom_score_adj if you really wanted to, but that would force the user to 
recalculate the value anytime the task's cpuset, mempolicy, or memcg 
changes.

> > > Usual disto alreay enables it.
> > > 
> > 
> > Yes, I'm well aware of my 40MB of lost memory on my laptop :)
> > 
> Very sorry ;)
> But it's required to track memory usage from init...
> 

Memcg comes with a cost of ~1% of system memory on x86 since
struct page_cgroup is ~1% of a 4K page.  That means if we were to deploy 
memcg on all of our servers and the number of jobs we can run is 
constrained only by memory, it's equivalent to losing ~1% of our servers.  
That, for us, is very large.

This is a different topic entirely, but it's a very significant 
disadvantage and enough that most people who care about oom killing 
prioritization aren't going to wany to incur such an overhead by enabling 
memcg or setting up individual memcg for each and every job, because that 
requires specific knowledge of all those jobs.

I'm not by any means proposing oom_score_adj as being very popular for the 
usual desktop environments :)

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

  parent reply	other threads:[~2010-08-03  1:46 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-17 19:16 David Rientjes
2010-07-17 19:16 ` [patch -mm 2/2] oom: deprecate oom_adj tunable David Rientjes
2010-07-29 23:08 ` [patch -mm 1/2] oom: badness heuristic rewrite Andrew Morton
2010-07-30  0:12   ` KOSAKI Motohiro
2010-07-30  1:38     ` Andrew Morton
2010-07-30 11:02       ` KOSAKI Motohiro
2010-07-30 20:14         ` David Rientjes
2010-08-02 20:43         ` Andrew Morton
2010-08-03  0:00           ` KAMEZAWA Hiroyuki
2010-08-03  0:27             ` David Rientjes
2010-08-03  0:36               ` KAMEZAWA Hiroyuki
2010-08-03  1:02                 ` David Rientjes
2010-08-03  1:08                   ` KAMEZAWA Hiroyuki
2010-08-03  1:24                     ` KAMEZAWA Hiroyuki
2010-08-03  1:52                       ` David Rientjes
2010-08-03  2:05                         ` KAMEZAWA Hiroyuki
2010-08-03  3:05                           ` David Rientjes
2010-08-03  3:11                             ` KAMEZAWA Hiroyuki
2010-08-03  4:20                               ` David Rientjes
2010-08-03  4:32                                 ` KAMEZAWA Hiroyuki
2010-08-03  7:23                                   ` David Rientjes
2010-08-03  7:21                                     ` KAMEZAWA Hiroyuki
2010-08-03  7:27                                       ` KAMEZAWA Hiroyuki
2010-08-03 20:43                                         ` David Rientjes
2010-08-03  1:50                     ` David Rientjes [this message]
2010-08-03  1:50                       ` KAMEZAWA Hiroyuki
2010-08-03  6:00           ` KOSAKI Motohiro
2010-08-03  7:16             ` 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.1008021837370.19184@chino.kir.corp.google.com \
    --to=rientjes@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=balbir@in.ibm.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-mm@kvack.org \
    --cc=npiggin@suse.de \
    --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