From: Chintan Pandya <cpandya@codeaurora.org>
To: David Rientjes <rientjes@google.com>
Cc: Michal Hocko <mhocko@suse.cz>,
hannes@cmpxchg.org, linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] memcg: Provide knob for force OOM into the memcg
Date: Wed, 17 Dec 2014 17:17:47 +0530 [thread overview]
Message-ID: <54916D63.7060701@codeaurora.org> (raw)
In-Reply-To: <alpine.DEB.2.10.1412161430040.5142@chino.kir.corp.google.com>
On 12/17/2014 04:03 AM, David Rientjes wrote:
> On Tue, 16 Dec 2014, Michal Hocko wrote:
>
>>> We may want to use memcg to limit the total memory
>>> footprint of all the processes within the one group.
>>> This may lead to a situation where any arbitrary
>>> process cannot get migrated to that one memcg
>>> because its limits will be breached. Or, process can
>>> get migrated but even being most recently used
>>> process, it can get killed by in-cgroup OOM. To
>>> avoid such scenarios, provide a convenient knob
>>> by which we can forcefully trigger OOM and make
>>> a room for upcoming process.
>>>
>>> To trigger force OOM,
>>> $ echo 1> /<memcg_path>/memory.force_oom
>>
>> What would prevent another task deplete that memory shortly after you
>> triggered OOM and end up in the same situation? E.g. while the moving
>> task is migrating its charges to the new group...
Idea was to trigger an OOM until we can migrate any particular process
onto desired cgroup.
>>
>> Why cannot you simply disable OOM killer in that memcg and handle it
>> from userspace properly?
Well, this can be done it seems. Let me explore around this. Thanks for
this suggestion.
> It seems to be proposed as a shortcut so that the kernel will determine
> the best process to kill. That information is available to userspace so
> it should be able to just SIGKILL the desired process (either in the
> destination memcg or in the source memcg to allow deletion), so this
> functionality isn't needed in the kernel.
Yes, this can be seen as a shortcut because we are off-loading some
task-selection to be killed by OOM on kernel rather than userspace
decides by itself.
--
Chintan Pandya
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of the Code Aurora Forum, hosted by The Linux Foundation
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Chintan Pandya <cpandya@codeaurora.org>
To: David Rientjes <rientjes@google.com>
Cc: Michal Hocko <mhocko@suse.cz>,
hannes@cmpxchg.org, linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] memcg: Provide knob for force OOM into the memcg
Date: Wed, 17 Dec 2014 17:17:47 +0530 [thread overview]
Message-ID: <54916D63.7060701@codeaurora.org> (raw)
In-Reply-To: <alpine.DEB.2.10.1412161430040.5142@chino.kir.corp.google.com>
On 12/17/2014 04:03 AM, David Rientjes wrote:
> On Tue, 16 Dec 2014, Michal Hocko wrote:
>
>>> We may want to use memcg to limit the total memory
>>> footprint of all the processes within the one group.
>>> This may lead to a situation where any arbitrary
>>> process cannot get migrated to that one memcg
>>> because its limits will be breached. Or, process can
>>> get migrated but even being most recently used
>>> process, it can get killed by in-cgroup OOM. To
>>> avoid such scenarios, provide a convenient knob
>>> by which we can forcefully trigger OOM and make
>>> a room for upcoming process.
>>>
>>> To trigger force OOM,
>>> $ echo 1> /<memcg_path>/memory.force_oom
>>
>> What would prevent another task deplete that memory shortly after you
>> triggered OOM and end up in the same situation? E.g. while the moving
>> task is migrating its charges to the new group...
Idea was to trigger an OOM until we can migrate any particular process
onto desired cgroup.
>>
>> Why cannot you simply disable OOM killer in that memcg and handle it
>> from userspace properly?
Well, this can be done it seems. Let me explore around this. Thanks for
this suggestion.
> It seems to be proposed as a shortcut so that the kernel will determine
> the best process to kill. That information is available to userspace so
> it should be able to just SIGKILL the desired process (either in the
> destination memcg or in the source memcg to allow deletion), so this
> functionality isn't needed in the kernel.
Yes, this can be seen as a shortcut because we are off-loading some
task-selection to be killed by OOM on kernel rather than userspace
decides by itself.
--
Chintan Pandya
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of the Code Aurora Forum, hosted by The Linux Foundation
next prev parent reply other threads:[~2014-12-17 11:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-16 13:25 [PATCH] memcg: Provide knob for force OOM into the memcg Chintan Pandya
2014-12-16 13:25 ` Chintan Pandya
2014-12-16 13:39 ` Michal Hocko
2014-12-16 13:39 ` Michal Hocko
[not found] ` <20141216133935.GK22914-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2014-12-16 22:33 ` David Rientjes
2014-12-16 22:33 ` David Rientjes
2014-12-16 22:33 ` David Rientjes
2014-12-17 11:47 ` Chintan Pandya [this message]
2014-12-17 11:47 ` Chintan Pandya
2014-12-16 16:59 ` Johannes Weiner
2014-12-16 16:59 ` Johannes Weiner
[not found] ` <20141216165922.GA30984-HTCKtW7iVlxqnrmGgq4/JMIURNUf+fel@public.gmane.org>
2014-12-17 12:11 ` Chintan Pandya
2014-12-17 12:11 ` Chintan Pandya
2014-12-17 12:11 ` Chintan Pandya
2014-12-19 21:15 ` Johannes Weiner
2014-12-19 21:15 ` 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=54916D63.7060701@codeaurora.org \
--to=cpandya@codeaurora.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--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 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.