From: Chintan Pandya <cpandya@codeaurora.org>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: mhocko@suse.cz, 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:41:29 +0530 [thread overview]
Message-ID: <549172F1.5050303@codeaurora.org> (raw)
In-Reply-To: <20141216165922.GA30984@phnom.home.cmpxchg.org>
> Why do you move tasks around during runtime? Rather than scanning
> thousands or millions of page table entries to relocate a task and its
> private memory to another configuration domain, wouldn't it be easier to
> just keep the task in a dedicated cgroup and reconfigure that instead?
Your suggestion is good. But in specific cases, we may have no choice
but to migrate.
Take a case of an Android system where a process/app will never gets
killed until there is really no scope of holding it any longer in RAM.
So, when that process was running as a foreground process, it has to
belong to a group which has no memory limit and cannot be killed. Now,
when the same process goes into background and sits idle, it can be
compressed and cached into some space in RAM. These cached processes are
ever growing list and can be capped with some limit. Naturally, these
processes belongs to different category and hence different cgroup which
just controls such cached processes.
>
> There doesn't seem to be a strong usecase for charge migration that
> couldn't be solved by doing things slightly differently from userspace.
> Certainly not something that justifies the complexity that it adds to
> memcg model and it's synchronization requirements from VM hotpaths.
> Hence, I'm inclined to not add charge moving to version 2 of memcg.
Do you say charge migration is discouraged at runtime ? Difficult to
live with this limitation.
--
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 12:11 UTC|newest]
Thread overview: 7+ 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:39 ` Michal Hocko
2014-12-16 22:33 ` David Rientjes
2014-12-17 11:47 ` Chintan Pandya
2014-12-16 16:59 ` Johannes Weiner
2014-12-17 12:11 ` Chintan Pandya [this message]
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=549172F1.5050303@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 \
/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).