On Tue, Dec 16, 2014 at 06:55:35PM +0530, Chintan Pandya 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. 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? 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. -- 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>