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: Tue, 30 Jul 2013 16:09:13 +0200 [thread overview]
Message-ID: <20130730140913.GC15847@dhcp22.suse.cz> (raw)
In-Reply-To: <20130726212808.GD17975@cmpxchg.org>
On Fri 26-07-13 17:28:09, Johannes Weiner wrote:
[...]
> From: Johannes Weiner <hannes@cmpxchg.org>
> Subject: [patch] mm: memcg: rework and document OOM serialization
>
> 1. Remove the return value of mem_cgroup_oom_unlock().
>
> 2. Rename mem_cgroup_oom_lock() to mem_cgroup_oom_trylock().
>
> 3. Pull the prepare_to_wait() out of the memcg_oom_lock scope. This
> makes it more obvious that the task has to be on the waitqueue
> before attempting to OOM-trylock the hierarchy, to not miss any
> wakeups before going to sleep. It just didn't matter until now
> because it was all lumped together into the global memcg_oom_lock
> spinlock section.
>
> 4. Pull the mem_cgroup_oom_notify() out of the memcg_oom_lock scope.
> It is proctected by the hierarchical OOM-lock.
>
> 5. The memcg_oom_lock spinlock is only required to propagate the OOM
> lock in any given hierarchy atomically. Restrict its scope to
> mem_cgroup_oom_(trylock|unlock).
>
> 6. Do not wake up the waitqueue unconditionally at the end of the
> function. Only the lockholder has to wake up the next in line
> after releasing the lock.
>
> Note that the lockholder kicks off the OOM-killer, which in turn
> leads to wakeups from the uncharges of the exiting task. But any
> contender is not guaranteed to see them if it enters the OOM path
> after the OOM kills but before the lockholder releases the lock.
> Thus the wakeup has to be explicitely after releasing the lock.
>
> 7. Put the OOM task on the waitqueue before marking the hierarchy as
> under OOM as that is the point where we start to receive wakeups.
> No point in listening before being on the waitqueue.
>
> 8. Likewise, unmark the hierarchy before finishing the sleep, for
> symmetry.
>
OK, this looks better than what we have today, but still could be done
better IMO ;)
> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
> ---
> mm/memcontrol.c | 85 +++++++++++++++++++++++++++++++--------------------------
> 1 file changed, 47 insertions(+), 38 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 30ae46a..0d923df 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -2076,15 +2076,18 @@ static int mem_cgroup_soft_reclaim(struct mem_cgroup *root_memcg,
> return total;
> }
>
/* Protects oom_lock hierarchy consistent state and oom_notify chain */
> +static DEFINE_SPINLOCK(memcg_oom_lock);
> +
> /*
> * Check OOM-Killer is already running under our hierarchy.
> * If someone is running, return false.
> - * Has to be called with memcg_oom_lock
> */
[...]
> @@ -2195,45 +2197,52 @@ static bool mem_cgroup_handle_oom(struct mem_cgroup *memcg, gfp_t mask,
> int order)
> {
> struct oom_wait_info owait;
> - bool locked, need_to_kill;
> + bool locked;
>
> 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);
>
> - /* At first, try to OOM lock hierarchy under memcg.*/
> - spin_lock(&memcg_oom_lock);
> - locked = mem_cgroup_oom_lock(memcg);
> /*
> + * As with any blocking lock, a contender needs to start
> + * listening for wakeups before attempting the trylock,
> + * otherwise it can miss the wakeup from the unlock and sleep
> + * indefinitely. This is just open-coded because our locking
> + * is so particular to memcg hierarchies.
> + *
> * Even if signal_pending(), we can't quit charge() loop without
> * accounting. So, UNINTERRUPTIBLE is appropriate. But SIGKILL
> * under OOM is always welcomed, use TASK_KILLABLE here.
Could you take care of this paragraph as well, while you are at it,
please? I've always found it it confusing. I would remove it completely
I would remove it completely.
> */
> prepare_to_wait(&memcg_oom_waitq, &owait.wait, TASK_KILLABLE);
> - if (!locked || memcg->oom_kill_disable)
> - need_to_kill = false;
> + mem_cgroup_mark_under_oom(memcg);
> +
> + locked = mem_cgroup_oom_trylock(memcg);
> +
> if (locked)
> mem_cgroup_oom_notify(memcg);
> - spin_unlock(&memcg_oom_lock);
>
> - if (need_to_kill) {
> + if (locked && !memcg->oom_kill_disable) {
> + mem_cgroup_unmark_under_oom(memcg);
> finish_wait(&memcg_oom_waitq, &owait.wait);
> mem_cgroup_out_of_memory(memcg, mask, order);
Killing under hierarchy which is not under_oom sounds strange to me.
Cannot we just move finish_wait & unmark down after unlock? It would
also take care about incorrect memcg_oom_recover you have in oom_unlock
path. The ordering would also be more natural
prepare_wait
mark_under_oom
trylock
unlock
unmark_under_oom
finish_wait
> } else {
> schedule();
> + mem_cgroup_unmark_under_oom(memcg);
> finish_wait(&memcg_oom_waitq, &owait.wait);
> }
> - spin_lock(&memcg_oom_lock);
> - if (locked)
> - mem_cgroup_oom_unlock(memcg);
> - memcg_wakeup_oom(memcg);
> - spin_unlock(&memcg_oom_lock);
>
> - mem_cgroup_unmark_under_oom(memcg);
> + if (locked) {
> + mem_cgroup_oom_unlock(memcg);
> + /*
> + * There is no guarantee that a OOM-lock contender
> + * sees the wakeups triggered by the OOM kill
> + * uncharges. Wake any sleepers explicitely.
> + */
> + memcg_oom_recover(memcg);
This will be a noop because memcg is no longer under_oom (you wanted
memcg_wakeup_oom here I guess). Moreover, even the killed wouldn't wake
up anybody for the same reason.
> + }
>
> if (test_thread_flag(TIF_MEMDIE) || fatal_signal_pending(current))
> return false;
> --
> 1.8.3.2
>
--
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>
next prev parent reply other threads:[~2013-07-30 14:09 UTC|newest]
Thread overview: 34+ 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 ` [patch 1/6] arch: mm: remove obsolete init OOM protection Johannes Weiner
2013-07-26 13:00 ` Michal Hocko
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-26 13:07 ` Michal Hocko
2013-07-29 18:58 ` KOSAKI Motohiro
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-26 13:19 ` Michal Hocko
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-26 13:52 ` Michal Hocko
2013-07-26 18:46 ` Johannes Weiner
2013-07-29 12:45 ` Michal Hocko
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-26 14:16 ` Michal Hocko
2013-07-26 18:54 ` Johannes Weiner
2013-07-29 19:18 ` KOSAKI Motohiro
2013-07-29 19:44 ` Johannes Weiner
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-26 14:43 ` Michal Hocko
2013-07-26 21:28 ` Johannes Weiner
2013-07-29 14:12 ` Michal Hocko
2013-07-29 14:55 ` Johannes Weiner
2013-07-29 15:52 ` Michal Hocko
2013-07-30 14:09 ` Michal Hocko [this message]
2013-07-30 14:32 ` Johannes Weiner
2013-07-30 14:56 ` Michal Hocko
2013-07-25 22:31 ` [patch 3.2] memcg OOM robustness (x86 only) Johannes Weiner
2013-08-03 8:38 ` azurIt
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=20130730140913.GC15847@dhcp22.suse.cz \
--to=mhocko@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=azurit@pobox.sk \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
--cc=x86@kernel.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 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).