All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>
To: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
Cc: Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	KAMEZAWA Hiroyuki
	<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>,
	azurIt <azurit-Rm0zKEqwvD4@public.gmane.org>,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
	cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [patch 6/6] mm: memcg: do not trap chargers with full callstack on OOM
Date: Mon, 29 Jul 2013 17:52:43 +0200	[thread overview]
Message-ID: <20130729155243.GI4678@dhcp22.suse.cz> (raw)
In-Reply-To: <20130729145529.GW715-druUgvl0LCNAfugRpC6u6w@public.gmane.org>

On Mon 29-07-13 10:55:29, Johannes Weiner wrote:
> On Mon, Jul 29, 2013 at 04:12:50PM +0200, Michal Hocko wrote:
> > On Fri 26-07-13 17:28:09, Johannes Weiner wrote:
> > > On Fri, Jul 26, 2013 at 04:43:10PM +0200, Michal Hocko wrote:
> > > > On Thu 25-07-13 18:25:38, Johannes Weiner wrote:
> > > > > @@ -2189,31 +2191,20 @@ static void memcg_oom_recover(struct mem_cgroup *memcg)
> > > > >  }
> > > > >  
> > > > >  /*
> > > > > - * try to call OOM killer. returns false if we should exit memory-reclaim loop.
> > > > > + * try to call OOM killer
> > > > >   */
> > > > > -static bool mem_cgroup_handle_oom(struct mem_cgroup *memcg, gfp_t mask,
> > > > > -				  int order)
> > > > > +static void mem_cgroup_oom(struct mem_cgroup *memcg, gfp_t mask, int order)
> > > > >  {
> > > > > -	struct oom_wait_info owait;
> > > > > -	bool locked, need_to_kill;
> > > > > +	bool locked, need_to_kill = true;
> > > > >  
> > > > > -	owait.memcg = memcg;
> > > > > -	owait.wait.flags = 0;
> > > > > -	owait.wait.func = memcg_oom_wake_function;
> > > > > -	owait.wait.private = current;
> > > > > -	INIT_LIST_HEAD(&owait.wait.task_list);
> > > > > -	need_to_kill = true;
> > > > > -	mem_cgroup_mark_under_oom(memcg);
> > > > 
> > > > You are marking memcg under_oom only for the sleepers. So if we have
> > > > no sleepers then the memcg will never report it is under oom which
> > > > is a behavior change. On the other hand who-ever relies on under_oom
> > > > under such conditions (it would basically mean a busy loop reading
> > > > memory.oom_control) would be racy anyway so it is questionable it
> > > > matters at all. At least now when we do not have any active notification
> > > > that under_oom has changed.
> > > > 
> > > > Anyway, this shouldn't be a part of this patch so if you want it because
> > > > it saves a pointless hierarchy traversal then make it a separate patch
> > > > with explanation why the new behavior is still OK.
> > > 
> > > This made me think again about how the locking and waking in there
> > > works and I found a bug in this patch.
> > > 
> > > Basically, we have an open-coded sleeping lock in there and it's all
> > > obfuscated by having way too much stuffed into the memcg_oom_lock
> > > section.
> > > 
> > > Removing all the clutter, it becomes clear that I can't remove that
> > > (undocumented) final wakeup at the end of the function.  As with any
> > > lock, a contender has to be woken up after unlock.  We can't rely on
> > > the lock holder's OOM kill to trigger uncharges and wakeups, because a
> > > contender for the OOM lock could show up after the OOM kill but before
> > > the lock is released.  If there weren't any more wakeups, the
> > > contender would sleep indefinitely.
> > 
> > I have checked that path again and I still do not see how wakeup_oom
> > helps here. What prevents us from the following race then?
> > 
> > spin_lock(&memcg_oom_lock)
> > locked = mem_cgroup_oom_lock(memcg) # true
> > spin_unlock(&memcg_oom_lock)
> 
>                                                 prepare_to_wait()

For some reason that one disappeared from my screen ;)

> > 						spin_lock(&memcg_oom_lock)
> > 						locked = mem_cgroup_oom_lock(memcg) # false
> > 						spin_unlock(&memcg_oom_lock)
> > 						<resched>
> > mem_cgroup_out_of_memory()
> > 			<uncharge & memcg_oom_recover>
> > spin_lock(&memcg_oom_lock)
> > mem_cgroup_oom_unlock(memcg)
> > memcg_wakeup_oom(memcg)
> > 						schedule()
> > spin_unlock(&memcg_oom_lock)
> > mem_cgroup_unmark_under_oom(memcg)

-- 
Michal Hocko
SUSE Labs

WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@suse.cz>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	David Rientjes <rientjes@google.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	azurIt <azurit@pobox.sk>,
	linux-mm@kvack.org, cgroups@vger.kernel.org, x86@kernel.org,
	linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [patch 6/6] mm: memcg: do not trap chargers with full callstack on OOM
Date: Mon, 29 Jul 2013 17:52:43 +0200	[thread overview]
Message-ID: <20130729155243.GI4678@dhcp22.suse.cz> (raw)
Message-ID: <20130729155243.-RsmGU7u81EcakexNeV8zCq6GaBQ_H_piSUxFuozdbQ@z> (raw)
In-Reply-To: <20130729145529.GW715@cmpxchg.org>

On Mon 29-07-13 10:55:29, Johannes Weiner wrote:
> On Mon, Jul 29, 2013 at 04:12:50PM +0200, Michal Hocko wrote:
> > On Fri 26-07-13 17:28:09, Johannes Weiner wrote:
> > > On Fri, Jul 26, 2013 at 04:43:10PM +0200, Michal Hocko wrote:
> > > > On Thu 25-07-13 18:25:38, Johannes Weiner wrote:
> > > > > @@ -2189,31 +2191,20 @@ static void memcg_oom_recover(struct mem_cgroup *memcg)
> > > > >  }
> > > > >  
> > > > >  /*
> > > > > - * try to call OOM killer. returns false if we should exit memory-reclaim loop.
> > > > > + * try to call OOM killer
> > > > >   */
> > > > > -static bool mem_cgroup_handle_oom(struct mem_cgroup *memcg, gfp_t mask,
> > > > > -				  int order)
> > > > > +static void mem_cgroup_oom(struct mem_cgroup *memcg, gfp_t mask, int order)
> > > > >  {
> > > > > -	struct oom_wait_info owait;
> > > > > -	bool locked, need_to_kill;
> > > > > +	bool locked, need_to_kill = true;
> > > > >  
> > > > > -	owait.memcg = memcg;
> > > > > -	owait.wait.flags = 0;
> > > > > -	owait.wait.func = memcg_oom_wake_function;
> > > > > -	owait.wait.private = current;
> > > > > -	INIT_LIST_HEAD(&owait.wait.task_list);
> > > > > -	need_to_kill = true;
> > > > > -	mem_cgroup_mark_under_oom(memcg);
> > > > 
> > > > You are marking memcg under_oom only for the sleepers. So if we have
> > > > no sleepers then the memcg will never report it is under oom which
> > > > is a behavior change. On the other hand who-ever relies on under_oom
> > > > under such conditions (it would basically mean a busy loop reading
> > > > memory.oom_control) would be racy anyway so it is questionable it
> > > > matters at all. At least now when we do not have any active notification
> > > > that under_oom has changed.
> > > > 
> > > > Anyway, this shouldn't be a part of this patch so if you want it because
> > > > it saves a pointless hierarchy traversal then make it a separate patch
> > > > with explanation why the new behavior is still OK.
> > > 
> > > This made me think again about how the locking and waking in there
> > > works and I found a bug in this patch.
> > > 
> > > Basically, we have an open-coded sleeping lock in there and it's all
> > > obfuscated by having way too much stuffed into the memcg_oom_lock
> > > section.
> > > 
> > > Removing all the clutter, it becomes clear that I can't remove that
> > > (undocumented) final wakeup at the end of the function.  As with any
> > > lock, a contender has to be woken up after unlock.  We can't rely on
> > > the lock holder's OOM kill to trigger uncharges and wakeups, because a
> > > contender for the OOM lock could show up after the OOM kill but before
> > > the lock is released.  If there weren't any more wakeups, the
> > > contender would sleep indefinitely.
> > 
> > I have checked that path again and I still do not see how wakeup_oom
> > helps here. What prevents us from the following race then?
> > 
> > spin_lock(&memcg_oom_lock)
> > locked = mem_cgroup_oom_lock(memcg) # true
> > spin_unlock(&memcg_oom_lock)
> 
>                                                 prepare_to_wait()

For some reason that one disappeared from my screen ;)

> > 						spin_lock(&memcg_oom_lock)
> > 						locked = mem_cgroup_oom_lock(memcg) # false
> > 						spin_unlock(&memcg_oom_lock)
> > 						<resched>
> > mem_cgroup_out_of_memory()
> > 			<uncharge & memcg_oom_recover>
> > spin_lock(&memcg_oom_lock)
> > mem_cgroup_oom_unlock(memcg)
> > memcg_wakeup_oom(memcg)
> > 						schedule()
> > spin_unlock(&memcg_oom_lock)
> > mem_cgroup_unmark_under_oom(memcg)

-- 
Michal Hocko
SUSE Labs

WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@suse.cz>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	David Rientjes <rientjes@google.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	azurIt <azurit@pobox.sk>,
	linux-mm@kvack.org, cgroups@vger.kernel.org, x86@kernel.org,
	linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [patch 6/6] mm: memcg: do not trap chargers with full callstack on OOM
Date: Mon, 29 Jul 2013 17:52:43 +0200	[thread overview]
Message-ID: <20130729155243.GI4678@dhcp22.suse.cz> (raw)
In-Reply-To: <20130729145529.GW715@cmpxchg.org>

On Mon 29-07-13 10:55:29, Johannes Weiner wrote:
> On Mon, Jul 29, 2013 at 04:12:50PM +0200, Michal Hocko wrote:
> > On Fri 26-07-13 17:28:09, Johannes Weiner wrote:
> > > On Fri, Jul 26, 2013 at 04:43:10PM +0200, Michal Hocko wrote:
> > > > On Thu 25-07-13 18:25:38, Johannes Weiner wrote:
> > > > > @@ -2189,31 +2191,20 @@ static void memcg_oom_recover(struct mem_cgroup *memcg)
> > > > >  }
> > > > >  
> > > > >  /*
> > > > > - * try to call OOM killer. returns false if we should exit memory-reclaim loop.
> > > > > + * try to call OOM killer
> > > > >   */
> > > > > -static bool mem_cgroup_handle_oom(struct mem_cgroup *memcg, gfp_t mask,
> > > > > -				  int order)
> > > > > +static void mem_cgroup_oom(struct mem_cgroup *memcg, gfp_t mask, int order)
> > > > >  {
> > > > > -	struct oom_wait_info owait;
> > > > > -	bool locked, need_to_kill;
> > > > > +	bool locked, need_to_kill = true;
> > > > >  
> > > > > -	owait.memcg = memcg;
> > > > > -	owait.wait.flags = 0;
> > > > > -	owait.wait.func = memcg_oom_wake_function;
> > > > > -	owait.wait.private = current;
> > > > > -	INIT_LIST_HEAD(&owait.wait.task_list);
> > > > > -	need_to_kill = true;
> > > > > -	mem_cgroup_mark_under_oom(memcg);
> > > > 
> > > > You are marking memcg under_oom only for the sleepers. So if we have
> > > > no sleepers then the memcg will never report it is under oom which
> > > > is a behavior change. On the other hand who-ever relies on under_oom
> > > > under such conditions (it would basically mean a busy loop reading
> > > > memory.oom_control) would be racy anyway so it is questionable it
> > > > matters at all. At least now when we do not have any active notification
> > > > that under_oom has changed.
> > > > 
> > > > Anyway, this shouldn't be a part of this patch so if you want it because
> > > > it saves a pointless hierarchy traversal then make it a separate patch
> > > > with explanation why the new behavior is still OK.
> > > 
> > > This made me think again about how the locking and waking in there
> > > works and I found a bug in this patch.
> > > 
> > > Basically, we have an open-coded sleeping lock in there and it's all
> > > obfuscated by having way too much stuffed into the memcg_oom_lock
> > > section.
> > > 
> > > Removing all the clutter, it becomes clear that I can't remove that
> > > (undocumented) final wakeup at the end of the function.  As with any
> > > lock, a contender has to be woken up after unlock.  We can't rely on
> > > the lock holder's OOM kill to trigger uncharges and wakeups, because a
> > > contender for the OOM lock could show up after the OOM kill but before
> > > the lock is released.  If there weren't any more wakeups, the
> > > contender would sleep indefinitely.
> > 
> > I have checked that path again and I still do not see how wakeup_oom
> > helps here. What prevents us from the following race then?
> > 
> > spin_lock(&memcg_oom_lock)
> > locked = mem_cgroup_oom_lock(memcg) # true
> > spin_unlock(&memcg_oom_lock)
> 
>                                                 prepare_to_wait()

For some reason that one disappeared from my screen ;)

> > 						spin_lock(&memcg_oom_lock)
> > 						locked = mem_cgroup_oom_lock(memcg) # false
> > 						spin_unlock(&memcg_oom_lock)
> > 						<resched>
> > mem_cgroup_out_of_memory()
> > 			<uncharge & memcg_oom_recover>
> > spin_lock(&memcg_oom_lock)
> > mem_cgroup_oom_unlock(memcg)
> > memcg_wakeup_oom(memcg)
> > 						schedule()
> > spin_unlock(&memcg_oom_lock)
> > mem_cgroup_unmark_under_oom(memcg)

-- 
Michal Hocko
SUSE Labs

--
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:[~2013-07-29 15:52 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-25 22:25 [patch 0/6] improve memcg oom killer robustness Johannes Weiner
2013-07-25 22:25 ` Johannes Weiner
2013-07-25 22:25 ` [patch 1/6] arch: mm: remove obsolete init OOM protection Johannes Weiner
2013-07-25 22:25   ` Johannes Weiner
2013-07-26 13:00   ` Michal Hocko
2013-07-26 13:00     ` Michal Hocko
2013-07-29 18:55   ` KOSAKI Motohiro
2013-07-29 18:55     ` KOSAKI Motohiro
2013-07-25 22:25 ` [patch 2/6] arch: mm: do not invoke OOM killer on kernel fault OOM Johannes Weiner
2013-07-25 22:25   ` Johannes Weiner
2013-07-26 13:07   ` Michal Hocko
2013-07-26 13:07     ` Michal Hocko
     [not found]   ` <1374791138-15665-3-git-send-email-hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2013-07-29 18:58     ` KOSAKI Motohiro
2013-07-29 18:58       ` KOSAKI Motohiro
2013-07-29 18:58       ` KOSAKI Motohiro
2013-08-01 21:59       ` Johannes Weiner
2013-08-01 21:59         ` Johannes Weiner
2013-07-25 22:25 ` [patch 3/6] arch: mm: pass userspace fault flag to generic fault handler Johannes Weiner
2013-07-25 22:25   ` Johannes Weiner
     [not found]   ` <1374791138-15665-4-git-send-email-hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2013-07-26 13:19     ` Michal Hocko
2013-07-26 13:19       ` Michal Hocko
2013-07-26 13:19       ` Michal Hocko
2013-07-26 18:45       ` Johannes Weiner
2013-07-26 18:45         ` Johannes Weiner
2013-07-25 22:25 ` [patch 4/6] x86: finish user fault error path with fatal signal Johannes Weiner
2013-07-25 22:25   ` Johannes Weiner
2013-07-26 13:52   ` Michal Hocko
2013-07-26 13:52     ` Michal Hocko
2013-07-26 18:46     ` Johannes Weiner
2013-07-26 18:46       ` Johannes Weiner
2013-07-29 12:45       ` Michal Hocko
2013-07-29 12:45         ` Michal Hocko
2013-07-29 19:01   ` KOSAKI Motohiro
2013-07-29 19:01     ` KOSAKI Motohiro
2013-07-25 22:25 ` [patch 5/6] mm: memcg: enable memcg OOM killer only for user faults Johannes Weiner
2013-07-25 22:25   ` Johannes Weiner
     [not found]   ` <1374791138-15665-6-git-send-email-hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2013-07-26 14:16     ` Michal Hocko
2013-07-26 14:16       ` Michal Hocko
2013-07-26 14:16       ` Michal Hocko
2013-07-26 18:54       ` Johannes Weiner
2013-07-26 18:54         ` Johannes Weiner
2013-07-29 19:18   ` KOSAKI Motohiro
2013-07-29 19:18     ` KOSAKI Motohiro
     [not found]     ` <51F6C00C.5050702-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-07-29 19:44       ` Johannes Weiner
2013-07-29 19:44         ` Johannes Weiner
2013-07-29 19:44         ` Johannes Weiner
2013-07-29 19:47         ` KOSAKI Motohiro
2013-07-29 19:47           ` KOSAKI Motohiro
2013-07-25 22:25 ` [patch 6/6] mm: memcg: do not trap chargers with full callstack on OOM Johannes Weiner
2013-07-25 22:25   ` Johannes Weiner
     [not found]   ` <1374791138-15665-7-git-send-email-hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2013-07-26 14:43     ` Michal Hocko
2013-07-26 14:43       ` Michal Hocko
2013-07-26 14:43       ` Michal Hocko
2013-07-26 21:28       ` Johannes Weiner
2013-07-26 21:28         ` Johannes Weiner
2013-07-29 14:12         ` Michal Hocko
2013-07-29 14:12           ` Michal Hocko
     [not found]           ` <20130729141250.GF4678-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-07-29 14:55             ` Johannes Weiner
2013-07-29 14:55               ` Johannes Weiner
2013-07-29 14:55               ` Johannes Weiner
     [not found]               ` <20130729145529.GW715-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2013-07-29 15:52                 ` Michal Hocko [this message]
2013-07-29 15:52                   ` Michal Hocko
2013-07-29 15:52                   ` Michal Hocko
     [not found]         ` <20130726212808.GD17975-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2013-07-30 14:09           ` Michal Hocko
2013-07-30 14:09             ` Michal Hocko
2013-07-30 14:09             ` Michal Hocko
     [not found]             ` <20130730140913.GC15847-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-07-30 14:32               ` Johannes Weiner
2013-07-30 14:32                 ` Johannes Weiner
2013-07-30 14:32                 ` Johannes Weiner
     [not found]                 ` <20130730143228.GD715-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2013-07-30 14:56                   ` Michal Hocko
2013-07-30 14:56                     ` Michal Hocko
2013-07-30 14:56                     ` Michal Hocko
2013-07-25 22:31 ` [patch 3.2] memcg OOM robustness (x86 only) Johannes Weiner
2013-07-25 22:31   ` Johannes Weiner
2013-08-03  8:38   ` azurIt
2013-08-03  8:38     ` azurIt
2013-08-03 16:30     ` Johannes Weiner
2013-08-03 16:30       ` Johannes Weiner

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=20130729155243.GI4678@dhcp22.suse.cz \
    --to=mhocko-alswssmvlrq@public.gmane.org \
    --cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
    --cc=azurit-Rm0zKEqwvD4@public.gmane.org \
    --cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
    --cc=kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org \
    --cc=linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
    --cc=rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
    --cc=x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    /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.