linux-kernel - Re: [PATCH] memcg: Provide knob for force OOM into the memcg

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <549172F1.5050303@codeaurora.org>
Date:	Wed, 17 Dec 2014 17:41:29 +0530
From:	Chintan Pandya <cpandya@...eaurora.org>
To:	Johannes Weiner <hannes@...xchg.org>
CC:	mhocko@...e.cz, linux-mm@...ck.org, cgroups@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] memcg: Provide knob for force OOM into the memcg

> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/