Hello, Max. On Tue, Nov 10, 2015 at 04:37:46PM +0100, Max Kellermann wrote: > > But what's the resource here? > > CPU consumption and memory bandwidth. A fork/clone is an operation Both are abstracted as CPU usage and controlled by the cpu controller. > that puts considerable load on a machine, most of which happens in > kernel space (copying page tables etc.). > > > All first-order resources which can be consumed by forking > > repeatedly already have proper controllers. > > They do? Yes. > I can limit CPU time with RLIMIT_CPU, but that's per-process and thus > completely useless. There's no cgroup controller with such a feature. There's the cpu controller > There's "cpu" which changes priority, "cpuset" selects CPUs, "cpuacct" The cpu controller can limit both in terms of relative weight and absolute CPU cycle bandwidth. > only does accounting and "freezer" (somewhat related). But nothing > that limits CPU usage according to configured rules. > > I can limit absolute memory usage with memcg, which is a good thing, > but is orthogonal to this feature. Note that there are already > various RLIMITs about memory usage, and despite that, memcg was > merged due to RLIMIT shortcomings. > > "pids" was merged even though there already was RLIMIT_NPROC. Again, > RLIMITs have their shortcomings. Because pids turned out to be a first-order resource which is not contrained by memory due to the limited pid space. > But which controllers can I use to achieve the same effect as my fork > limit feature? Did I miss one? Apparently. > > What's the point of adding an extra second-order controller? > > I explained that, and you just cited my explanation. > > > Where do we go from there? Limit on the number of syscalls? > > No idea. Are these questions really relevant for my patch? Well, it's relevant to the fact that it's failing to distinguish what are actual resources and what aren't. Thanks. -- tejun -- 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
