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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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, 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>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]