From: Johannes Weiner <hannes@cmpxchg.org>
To: Michal Hocko <mhocko@suse.cz>
Cc: linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
David Rientjes <rientjes@google.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC 1/3] memcg: notify userspace about OOM only when and action is due
Date: Wed, 15 Jan 2014 12:56:55 -0500 [thread overview]
Message-ID: <20140115175655.GJ6963@cmpxchg.org> (raw)
In-Reply-To: <1389798068-19885-2-git-send-email-mhocko@suse.cz>
On Wed, Jan 15, 2014 at 04:01:06PM +0100, Michal Hocko wrote:
> Userspace is currently notified about OOM condition after reclaim
> fails to uncharge any memory after MEM_CGROUP_RECLAIM_RETRIES rounds.
> This usually means that the memcg is really in troubles and an
> OOM action (either done by userspace or kernel) has to be taken.
> The kernel OOM killer however bails out and doesn't kill anything
> if it sees an already dying/exiting task in a good hope a memory
> will be released and the OOM situation will be resolved.
>
> Therefore it makes sense to notify userspace only after really all
> measures have been taken and an userspace action is required or
> the kernel kills a task.
>
> This patch is based on idea by David Rientjes to not notify
> userspace when the current task is killed or in a late exiting.
> The original patch, however, didn't handle in kernel oom killer
> back offs which is implemtented by this patch.
>
> Signed-off-by: Michal Hocko <mhocko@suse.cz>
OOM is a temporary state because any task can exit at a time that is
not under our control and outside our knowledge. That's why the OOM
situation is defined by failing an allocation after a certain number
of reclaim and charge attempts.
As of right now, the OOM sampling window is MEM_CGROUP_RECLAIM_RETRIES
loops of charge attempts and reclaim. If a racing task is exiting and
releasing memory during that window, the charge will succeed fine. If
the sampling window is too short in practice, it will have to be
extended, preferrably through increasing MEM_CGROUP_RECLAIM_RETRIES.
But a random task exiting a split second after the sampling window has
closed will always be a possibility, regardless of how long it is.
There is nothing to be gained from this layering violation and it's
mind-boggling that you two still think this is a meaningful change.
Nacked-by: Johannes Weiner <hannes@cmpxchg.org>
--
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:[~2014-01-15 17:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-15 15:01 [RFC PATCH 0/3] memcg OOM notifications and PF_EXITING checks Michal Hocko
2014-01-15 15:01 ` [RFC 1/3] memcg: notify userspace about OOM only when and action is due Michal Hocko
2014-01-15 17:56 ` Johannes Weiner [this message]
2014-01-15 19:00 ` Michal Hocko
2014-01-15 20:30 ` Johannes Weiner
2014-01-16 14:10 ` Michal Hocko
2014-01-15 15:01 ` [RFC 2/3] memcg: do not check PF_EXITING in mem_cgroup_out_of_memory Michal Hocko
2014-01-15 15:01 ` [RFC 3/3] memcg,oom: do not check PF_EXITING and do not set TIF_MEMDIE Michal Hocko
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=20140115175655.GJ6963@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--cc=rientjes@google.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