Hello, On Fri, Jun 22, 2018 at 11:00:03AM +0800, Waiman Long wrote: > On 06/21/2018 05:20 PM, Peter Zijlstra wrote: > >> As for the inconsistency between the real root and the container root, > >> this is true for almost all the controllers. So it is a generic problem. > >> One possible solution is to create a kind a pseudo root cgroup for the > >> container that looks and feels like a real root. But is there really a > >> need to do that? > > I don't really know. I thought the idea was to make containers > > indistinguishable from a real system. Now I know we're really rather far > > away from that in reality, and I really have no clue how important all > > that is. > > That will certainly be the ideal. Sure, ideal in theoretical sense; however, the practical cost-benefit ratio of trying to make containers indistinguishible from system doesn't seem enough to justify the effort. Not yet anyway. It'd be nice to not paint ourselves into a corner where we can't get the equivalence without major interface changes later but I think that's about the extent we should go for now. > > It all depends on how exactly this works; is it like I assumed, that > > this file is owned by the parent instead of the current directory? And > > that if you namespace this, you have an effective read-only file? > > Yes, that is right. > > > Then fixing the inconsistency is trivial; simply provide a read-only > > file for the actual root cgroup too. > > > > And if the solution is trivial, I don't see a good reason not to do it. > > Do you mean providing a flag like READONLY_AT_ROOT so that it will be > read-only at the real root? That is an cgroup architectural decision > that needs input from Tejun. Anyway, this issue is not specific to this > patchset and I would like to break it out as a separate discussion > independent of this patchset. Yeah, it's a larger problem than cpuset and different controllers trying it in different ways isn't a good idea anyway. Let's shelve this topic for now. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
