Hello, On Fri, Apr 27, 2012 at 11:56:12AM -0400, Vivek Goyal wrote: > > I find allowing unpriv users creating cgroups dumb. cgroup consumes > > kernel memory. Sans using kmemcg, what prevents them from creating > > gazillion cgroups and consuming all memories? The idea of allowing > > cgroups to !priv users is just broken from the get go. > > Well creating a task consumes memory too but we allow unpriv users to > create tasks. :-) We have ulimit. > May be a system wide cgroup limit will make sense? IMHO, this was one of the larger mistakes cgroup has made. There are two ways when building interface for admin stuff like this, you can either implement and expose the core functionality and let userland deal with distribution or build things such that the kernel can fully virtualize and distribute the control to each process. Both approaches have their pros and cons but I generally think it's better to go for the latter for new and extra stuff like cgroup as it is much simpler and tends to more flexible and adapts better as use cases develop. The problem with cgroup is that it's neither the former or the latter. It's caught somewhere in the middle with its pants down where it does half-assed job of providing an interface which looks like it could be made to be directly accessible from !priv processes while not really being able to handle such usage. I mean, just think about the case you just raised. Forget about memory usage. What about weights? If you allow a random user to create arbitrary number of blkcg groups, [s]he gets 500 extra weight with each blkcg! Yeah! If we support full hierarchy on all controllers, exposing cgroups directly to !priv users may start to make more sense but I'd much prefer having resource policy controlled and administered centrally in userland. It's a job much better suited for userland. If such mechanism would require certain features, sure we can accomodate that but I think trying to allow !priv users directly to cgroup is stupid especially at this point, so let's just drop it. Thanks. -- tejun _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
