All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.cz>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>,
	Oleg Nesterov <oleg@redhat.com>,
	Konstantin Khlebnikov <khlebnikov@openvz.org>,
	linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	"Rafael J. Wysocki" <rjw@sisk.pl>
Subject: Re: [PATCH 2/2] oom: give bonus to frozen processes
Date: Mon, 26 Sep 2011 11:54:16 +0200	[thread overview]
Message-ID: <20110926095416.GG10156@tiehlicka.suse.cz> (raw)
In-Reply-To: <20110926183115.277afeb1.kamezawa.hiroyu@jp.fujitsu.com>

On Mon 26-09-11 18:31:15, KAMEZAWA Hiroyuki wrote:
> On Mon, 26 Sep 2011 02:02:59 -0700 (PDT)
> David Rientjes <rientjes@google.com> wrote:
> 
> > On Mon, 26 Sep 2011, Michal Hocko wrote:
> > 
> > > Let's try it with a heuristic change first. If you really do not like
> > > it, we can move to oom_scode_adj. I like the heuristic change little bit
> > > more because it is at the same place as the root bonus.
> > 
> > The problem with the bonus is that, as mentioned previously, it doesn't 
> > protect against ANYTHING for the case you're trying to fix.  

Yes, it just makes this less probable.


> > This won't panic the machine because all killable threads are
> > guaranteed to have a non-zero badness score, but it's a very valid
> > configuration to have either
> > 
> >  - all eligible threads (system-wide, shared cpuset, shared mempolicy 
> >    nodes) are frozen, or
> > 
> >  - all eligible frozen threads use <5% of memory whereas all other 
> >    eligible killable threads use 1% of available memory.
> > 
> > and that means the oom killer will repeatedly select those threads and the 
> > livelock still exists unless you can guarantee that they are successfully 
> > thawed, that thawing them in all situations is safe, and that once thawed 
> > they will make a timely exit.

Yes, this is what the first patch is fixing. Thawed tasks should die
almost immediately because they are on the way to userspace anyway.

> > 
> > Additionally, I don't think biasing against frozen tasks makes sense from 
> > a heusritic standpoint of the oom killer.  Why would we want give 
> > non-frozen tasks that are actually getting work done a preference over a 
> > task that is frozen and doing absolutely nothing?  

Because frozen tasks are in that state usually (not considering suspend
path which has OOM disabled) based on an user request (via freezer
cgroup e.g.). I wouldn't be surprised if somebody relied on the D state
and that the task will not get killer.

> > It seems like that's backwards and that we'd actually prefer killing
> > the task doing nothing so it can free its memory.
> > 
> 
> I agree with David.
> Why don't you set oom_score_adj as -1000 for processes which never should die ?

It is little bit unintuitive to think about OOM killer when you just
want to debug your frozen application.
On the other hand I agree that adding a new heuristic for an use case
that is not entirely clear and which is not 100% anyway is not good.

So, please scratch this patch and let's wait for somebody with a valid
use case.

> You don't freeze processes via user-land using cgroup ?

That was exactly the use case I had in mind. Somebody using freezer
cgroup to freeze a task to debug it.

> 
> Thanks,
> -Kame
> 
> 
> 
> --
> 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>

-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@suse.cz>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>,
	Oleg Nesterov <oleg@redhat.com>,
	Konstantin Khlebnikov <khlebnikov@openvz.org>,
	linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	"Rafael J. Wysocki" <rjw@sisk.pl>
Subject: Re: [PATCH 2/2] oom: give bonus to frozen processes
Date: Mon, 26 Sep 2011 11:54:16 +0200	[thread overview]
Message-ID: <20110926095416.GG10156@tiehlicka.suse.cz> (raw)
In-Reply-To: <20110926183115.277afeb1.kamezawa.hiroyu@jp.fujitsu.com>

On Mon 26-09-11 18:31:15, KAMEZAWA Hiroyuki wrote:
> On Mon, 26 Sep 2011 02:02:59 -0700 (PDT)
> David Rientjes <rientjes@google.com> wrote:
> 
> > On Mon, 26 Sep 2011, Michal Hocko wrote:
> > 
> > > Let's try it with a heuristic change first. If you really do not like
> > > it, we can move to oom_scode_adj. I like the heuristic change little bit
> > > more because it is at the same place as the root bonus.
> > 
> > The problem with the bonus is that, as mentioned previously, it doesn't 
> > protect against ANYTHING for the case you're trying to fix.  

Yes, it just makes this less probable.


> > This won't panic the machine because all killable threads are
> > guaranteed to have a non-zero badness score, but it's a very valid
> > configuration to have either
> > 
> >  - all eligible threads (system-wide, shared cpuset, shared mempolicy 
> >    nodes) are frozen, or
> > 
> >  - all eligible frozen threads use <5% of memory whereas all other 
> >    eligible killable threads use 1% of available memory.
> > 
> > and that means the oom killer will repeatedly select those threads and the 
> > livelock still exists unless you can guarantee that they are successfully 
> > thawed, that thawing them in all situations is safe, and that once thawed 
> > they will make a timely exit.

Yes, this is what the first patch is fixing. Thawed tasks should die
almost immediately because they are on the way to userspace anyway.

> > 
> > Additionally, I don't think biasing against frozen tasks makes sense from 
> > a heusritic standpoint of the oom killer.  Why would we want give 
> > non-frozen tasks that are actually getting work done a preference over a 
> > task that is frozen and doing absolutely nothing?  

Because frozen tasks are in that state usually (not considering suspend
path which has OOM disabled) based on an user request (via freezer
cgroup e.g.). I wouldn't be surprised if somebody relied on the D state
and that the task will not get killer.

> > It seems like that's backwards and that we'd actually prefer killing
> > the task doing nothing so it can free its memory.
> > 
> 
> I agree with David.
> Why don't you set oom_score_adj as -1000 for processes which never should die ?

It is little bit unintuitive to think about OOM killer when you just
want to debug your frozen application.
On the other hand I agree that adding a new heuristic for an use case
that is not entirely clear and which is not 100% anyway is not good.

So, please scratch this patch and let's wait for somebody with a valid
use case.

> You don't freeze processes via user-land using cgroup ?

That was exactly the use case I had in mind. Somebody using freezer
cgroup to freeze a task to debug it.

> 
> Thanks,
> -Kame
> 
> 
> 
> --
> 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>

-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

--
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-09-26  9:54 UTC|newest]

Thread overview: 88+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-23  8:31 [PATCH] oom: skip frozen tasks Konstantin Khlebnikov
2011-08-23  8:31 ` Konstantin Khlebnikov
2011-08-23  9:15 ` KAMEZAWA Hiroyuki
2011-08-23  9:15   ` KAMEZAWA Hiroyuki
2011-08-23 13:46 ` Michal Hocko
2011-08-23 13:46   ` Michal Hocko
2011-08-23 20:18 ` David Rientjes
2011-08-23 20:18   ` David Rientjes
2011-08-24 10:19   ` Michal Hocko
2011-08-24 10:19     ` Michal Hocko
2011-08-24 19:31     ` David Rientjes
2011-08-24 19:31       ` David Rientjes
2011-08-25  9:19       ` Michal Hocko
2011-08-25  9:19         ` Michal Hocko
2011-08-25 15:18         ` Oleg Nesterov
2011-08-25 15:18           ` Oleg Nesterov
2011-08-25 16:47           ` Michal Hocko
2011-08-25 16:47             ` Michal Hocko
2011-08-25 21:14             ` David Rientjes
2011-08-25 21:14               ` David Rientjes
2011-08-26  7:09               ` Michal Hocko
2011-08-26  7:09                 ` Michal Hocko
2011-08-26  8:56                 ` Michal Hocko
2011-08-26  8:56                   ` Michal Hocko
2011-08-26  9:21                   ` David Rientjes
2011-08-26  9:21                     ` David Rientjes
2011-08-26  9:53                     ` Michal Hocko
2011-08-26  9:53                       ` Michal Hocko
2011-08-26 11:01                       ` Michal Hocko
2011-08-26 11:01                         ` Michal Hocko
2011-08-26 18:13                       ` David Rientjes
2011-08-26 18:13                         ` David Rientjes
2011-09-26  8:28                         ` [PATCH 1/2] oom: do not live lock on " Michal Hocko
2011-09-26  8:28                           ` Michal Hocko
2011-09-26  8:56                           ` David Rientjes
2011-09-26  8:56                             ` David Rientjes
2011-09-26  9:14                             ` Michal Hocko
2011-09-26  9:14                               ` Michal Hocko
2011-09-26  9:25                               ` KAMEZAWA Hiroyuki
2011-09-26  9:25                                 ` KAMEZAWA Hiroyuki
2011-09-26  9:32                                 ` Michal Hocko
2011-09-26  9:32                                   ` Michal Hocko
2011-09-26 15:51                               ` Rafael J. Wysocki
2011-09-26 15:51                                 ` Rafael J. Wysocki
2011-09-26 18:28                                 ` Michal Hocko
2011-09-26 18:28                                   ` Michal Hocko
2011-09-27  1:03                                 ` David Rientjes
2011-09-27  1:03                                   ` David Rientjes
2011-09-27  7:52                                   ` Michal Hocko
2011-09-27  7:52                                     ` Michal Hocko
2011-09-27 18:30                                     ` David Rientjes
2011-09-27 18:30                                       ` David Rientjes
2011-09-26 10:28                           ` Rusty Russell
2011-09-26 10:28                             ` Rusty Russell
2011-09-26 11:05                             ` Michal Hocko
2011-09-26 11:05                               ` Michal Hocko
2011-09-27  2:21                               ` Rusty Russell
2011-09-27  2:21                                 ` Rusty Russell
2011-09-27  7:03                                 ` [PATCH] lguest: move process freezing before pending signals check Michal Hocko
2011-09-27  7:03                                   ` Michal Hocko
2011-09-26  8:35                         ` [PATCH 2/2] oom: give bonus to frozen processes Michal Hocko
2011-09-26  8:35                           ` Michal Hocko
2011-09-26  9:02                           ` David Rientjes
2011-09-26  9:02                             ` David Rientjes
2011-09-26  9:31                             ` KAMEZAWA Hiroyuki
2011-09-26  9:31                               ` KAMEZAWA Hiroyuki
2011-09-26  9:54                               ` Michal Hocko [this message]
2011-09-26  9:54                                 ` Michal Hocko
2011-08-26 21:03                     ` [PATCH] oom: skip frozen tasks Rafael J. Wysocki
2011-08-26 21:03                       ` Rafael J. Wysocki
2011-08-26 10:03                   ` Konstantin Khlebnikov
2011-08-26 10:03                     ` Konstantin Khlebnikov
2011-08-26 10:48                     ` Michal Hocko
2011-08-26 10:48                       ` Michal Hocko
2011-08-26 12:44                       ` Konstantin Khlebnikov
2011-08-26 12:44                         ` Konstantin Khlebnikov
2011-08-26 12:59                         ` Michal Hocko
2011-08-26 12:59                           ` Michal Hocko
2011-08-26  7:35               ` Konstantin Khlebnikov
2011-08-26  7:35                 ` Konstantin Khlebnikov
2011-08-26  9:09                 ` David Rientjes
2011-08-26  9:09                   ` David Rientjes
2011-08-26  9:59                   ` Konstantin Khlebnikov
2011-08-26  9:59                     ` Konstantin Khlebnikov
2011-08-26 18:09                     ` David Rientjes
2011-08-26 18:09                       ` David Rientjes
2011-08-25 21:03           ` Rafael J. Wysocki
2011-08-25 21:03             ` Rafael J. Wysocki

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=20110926095416.GG10156@tiehlicka.suse.cz \
    --to=mhocko@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=khlebnikov@openvz.org \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=oleg@redhat.com \
    --cc=rientjes@google.com \
    --cc=rjw@sisk.pl \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.