linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Figo.zhang" <figo1802@gmail.com>
To: David Rientjes <rientjes@google.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	"Figo.zhang" <zhangtianfei@leadcoretech.com>,
	lkml <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH v2]oom-kill: CAP_SYS_RESOURCE should get bonus
Date: Wed, 10 Nov 2010 22:38:11 +0800	[thread overview]
Message-ID: <1289399891.10699.14.camel@localhost.localdomain> (raw)
In-Reply-To: <alpine.DEB.2.00.1011091300510.7730@chino.kir.corp.google.com>

On Tue, 2010-11-09 at 13:06 -0800, David Rientjes wrote:
> On Tue, 9 Nov 2010, Alan Cox wrote:
> 
> > The reverse can be argued equally - that they can unprotect themselves if
> > necessary. In fact it seems to be a "point of view" sort of question
> > which way you deal with CAP_SYS_RESOURCE, and that to me argues that
> > changing from old expected behaviour to a new behaviour is a regression.
> > 
> 
> I didn't check earlier, but CAP_SYS_RESOURCE hasn't had a place in the oom 
> killer's heuristic in over five years, so what regression are we referring 
> to in this thread?  These tasks already have full control over 
> oom_score_adj to modify its oom killing priority in either direction.

yes, it can control by user, but is it all system administrators will
adjust all of the processes by each one and one in real word? suppose if
it has thousands of processes in database system.

> Futhermore, the heuristic was entirely rewritten, but I wouldn't consider 
> all the old factors such as cputime and nice level being removed as 
> "regressions" since the aim was to make it more predictable and more 
> likely to kill a large consumer of memory such that we don't have to kill 
> more tasks in the near future.

the goal of oom_killer is to find out the best process to kill, the one
should be:
1. it is a most memory comsuming process in all processes
2. and it was a proper process to kill, which will not be let system 
into unpredictable state as possible.

if a user process and a process such email cleint "evolution" with
ditecly hareware access such as "Xorg", they have eat the equal memory,
so which process are you want to kill?



  parent reply	other threads:[~2010-11-10 14:39 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-02  1:43 [PATCH]oom-kill: direct hardware access processes should get bonus Figo.zhang
2010-11-02  3:10 ` David Rientjes
2010-11-02 14:24   ` Figo.zhang
2010-11-02 19:34     ` David Rientjes
2010-11-03 23:43 ` [PATCH v2]oom-kill: CAP_SYS_RESOURCE " Figo.zhang
2010-11-03 23:47   ` David Rientjes
     [not found]     ` <AANLkTimjfmLzr_9+Sf4gk0xGkFjffQ1VcCnwmCXA88R8@mail.gmail.com>
2010-11-04  1:38       ` Figo.zhang
2010-11-04  1:50         ` David Rientjes
2010-11-04  2:12           ` Figo.zhang
2010-11-04  2:54             ` David Rientjes
2010-11-04  4:42               ` Figo.zhang
2010-11-04  5:08                 ` David Rientjes
2010-11-09 11:01           ` [PATCH " KOSAKI Motohiro
2010-11-09 12:24             ` Alan Cox
2010-11-09 21:06               ` David Rientjes
2010-11-09 21:25                 ` David Rientjes
2010-11-10 14:38                 ` Figo.zhang [this message]
2010-11-10 20:50                   ` David Rientjes
2010-11-09 10:41 ` [PATCH]oom-kill: direct hardware access processes " KOSAKI Motohiro
2010-11-09 12:24 ` [PATCH v2]mm/oom-kill: " Figo.zhang
2010-11-09 21:16   ` David Rientjes
2010-11-10 14:48     ` Figo.zhang
2010-11-14  5:07     ` KOSAKI Motohiro
2010-11-14 21:29       ` David Rientjes
2010-11-15  1:24         ` KOSAKI Motohiro
2010-11-15 10:03           ` David Rientjes
2010-11-23  7:16             ` KOSAKI Motohiro
2010-11-28  1:36               ` David Rientjes
2010-11-30 13:00                 ` KOSAKI Motohiro
2010-11-30 20:05                   ` David Rientjes
2010-11-10 15:14   ` [PATCH v3]mm/oom-kill: " Figo.zhang
2010-11-10 15:24     ` Figo.zhang
2010-11-10 21:00       ` David Rientjes
2010-11-14  5:21       ` KOSAKI Motohiro
2010-11-14 21:33         ` David Rientjes
2010-11-15  3:26           ` [PATCH] Revert oom rewrite series Figo.zhang
2010-11-15 10:14             ` David Rientjes
2010-11-15 10:57               ` Alan Cox
2010-11-15 20:54                 ` David Rientjes
2010-11-23  7:16                 ` KOSAKI Motohiro
2011-01-04  7:51       ` [PATCH v3]mm/oom-kill: direct hardware access processes should get bonus Figo.zhang
2011-01-04  8:28         ` KAMEZAWA Hiroyuki
2011-01-04  8:56           ` Figo.zhang
2011-01-06  0:55             ` KAMEZAWA Hiroyuki
2011-01-05  3:32         ` 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=1289399891.10699.14.camel@localhost.localdomain \
    --to=figo1802@gmail.com \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rientjes@google.com \
    --cc=zhangtianfei@leadcoretech.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).