Re: [RFD] Merge task counter into memcg
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
On 04/11/2012 10:57 PM, Frederic Weisbecker wrote:
Hi, While talking with Tejun about targetting the cgroup task counter subsystem for the next merge window, he suggested to check if this could be merged into the memcg subsystem rather than creating a new one cgroup subsystem just for task count limit purpose. So I'm pinging you guys to seek your insight. I assume not everybody in the Cc list knows what the task counter subsystem is all about. So here is a summary: this is a cgroup subsystem (latest version in https://lwn.net/Articles/478631/) that keeps track of the number of tasks present in a cgroup. Hooks are set in task fork/exit and cgroup migration to maintain this accounting visible to a special tasks.usage file. The user can set a limit on the number of tasks by writing on the tasks.limit file. Further forks or cgroup migration are then rejected if the limit is exceeded. This feature is especially useful to protect against forkbombs in containers. Or more generally to limit the resources on the number of tasks on a cgroup as it involves some kernel memory allocation. Now the dilemna is how to implement it? 1) As a standalone subsystem, as it stands currently (https://lwn.net/Articles/478631/) 2) As a feature in memcg, part of the memory.kmem.* files. This makes sense because this is about kernel memory allocation limitation. We could have a memory.kmem.tasks.count My personal opinion is that the task counter brings some overhead: a charge across the whole hierarchy at every fork, and the mirrored uncharge on task exit. And this overhead happens even in the off-case (when the task counter susbsystem is mounted but the limit is the default: ULLONG_MAX). So if we choose the second solution, this overhead will be added unconditionally to memcg. But I don't expect every users of memcg will need the task counter. So perhaps the overhead should be kept in its own separate subsystem. OTOH memory.kmem.* interface would have be a good fit. What do you think? -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,I'm agree that this is memory related thing, but I prefer this as a separate subsystem. Yes it has some impact on a system, but on the other hand we will have some very useful tool to track tasks state.
As I wrote before http://comments.gmane.org/gmane.linux.kernel.cgroups/1448it'll very useful to have event in the userspace about fork/exit about group of the processes.
-- Best regards, Alex Nikiforov, Mobile SW, Advanced Software Group, Moscow R&D center, Samsung Electronics _______________________________________________ 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]