Quoting Tejun Heo (tj@xxxxxxxxxx): > Hello, Serge. > > On Sun, Apr 14, 2013 at 08:13:36PM -0500, Serge Hallyn wrote: > > If I do > > > > cd /sys/fs/cgroup/memory > > mkdir b > > cd b > > echo 1 > memory.use_hierarchy > > echo 5000 > memory.limit_in_bytes > > cat memory.limit_in_bytes > > 8192 > > mkdir c > > cd c > > cat memory.use_hierarchy > > 1 > > cat memory.limit_in_bytes > > 9223372036854775807 > > echo $$ > tasks > > bash > > <killed> > > > > So it seems the hierarchy is being enforced, but not reported in > > child limit_in_bytes files. > > Hmm.... if I understand you correctly, it ain't bug. It's supposed to > work that way. The parent has certain limits and the child doesn't. > The child will operate within the paren't limits but in those limits > it isn't restricted. We actually have a controller which does > propagate configuration, the device security one, which I don't think > is really optimal but it seems to be the easier way to implement > hierarchical behavior for that controller. > > Anyways, if you think about the use cases, the current memcg way makes > a lot more sense and is more flexible. e.g. You can express things > like A + B shouldn't go above 1000 (whatever the unit is) but A and B > in each can go upto 700 when there's room. True, that makes sense, thanks. This example would be great to have in Documentation/cgroups/memory.txt. Perhaps as a new subsection 6.2? -serge -- 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
