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@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>