|
|
|
Re: [RFD] Merge task counter into memcg | |
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] | |
On 04/12/2012 10:42 PM, KAMEZAWA Hiroyuki wrote:
To be honest, I doubt that task counter is unnecessary...memcg can catch
oom situation well. I often test 'make -j' under memcg.
To the questions
* It sounds like a 'ulimit' cgroup. How about overwriting
ulimit values via cgroup ? (sounds joke?) Then, overhead will be small but
I'm not sure it can be hierarchical and doesn't break userland.
If people wants to limit the number of tasks, I think interface should provide it
in the unit of objects. Then, I'm ok to have other subsystem for counting something.
fork-bomb's memory overhead can be prevent by memcg. What memcg cannot handle
is ulimit. If forkbomb exhausts all ulimit/tasks, the user cannot login.
So, having task-limit cgroup subsys for a sandbox will make sense in some situation.
In short, I don't think it's better to have task-counting and fd-counting in memcg.
It's kmem, but it's more than that, I think.
Please provide subsys like ulimit.
Kame, You're talking about the memcg that is in the kernel today. I think the discussion is orbiting around how it is going to be once westart tracking kernel memory like the slab (for task_struct), or kernel stack pages.
In those scenarios, a fork bomb will be stopped anyway, because it will need kernel memory it can't grab.
_______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
[Cgroups] [Netdev] [Linux Wireless] [Kernel Newbies] [Memory] [Security] [Linux for Hams] [Netfilter] [Bugtraq] [Photo] [Yosemite] [Yosemite Forum] [MIPS Linux] [ARM Linux] [Linux RAID] [Linux Admin] [Find Someone Nice] [Samba] [Video 4 Linux] [Computer Add-ons]