Hello, Glauber. On Mon, Sep 17, 2012 at 12:50:47PM +0400, Glauber Costa wrote: > > Can you be a bit more specific? > > What I mean is that if some operation needs to operate locked, they will > have to lock. Whether or not the locking is called from cgroup core or > not. If the lock is not available outside, people will end up calling a > core function that locks. I was asking whether you have certain specific operations on mind. > >> And the problem is that people need to lock. cgroup_lock is needed > >> because the data you are accessing is protected by it. The way I see it, > >> it is incredible how we were able to revive the BKL in the form of > >> cgroup_lock after we finally manage to successfully get rid of it! > > > > I wouldn't go as far as comparing it to BKL. > > Of course not, since it is not system-wide. But I think the comparison > still holds in spirit... Subsystem-wide locks covering non-hot paths aren't evil things. We have a lot of them and they work fine. BKL was a completely different beast initially with implicit locking on kernel entry and unlocking on sleeping and then got morphed into some chimera inbetween afterwards. Simple locking is a good thing. If finer-grained locking is necessary, we sure do that but please stop throwing over-generalized half-arguments at it. It doesn't help anything. > you seem to hear "comount", and think of unified vision, and that is the > reason for this discussion to still be going on. Mounting is all about > the root. And if you comount, hierarchies have the same root. > > In your example, the different controllers are comounted. They have not > the same view, but the possible views are restricted to be a subset of > the underlying tree - because they are mounted in the same place, forced > or not. Heh, I can't really tell whether you understand it or not. Here and in the previous thread too. You seem to understand that there are different views upto this point. > In a situation like this, it makes all the sense in the world to use the > css_id as a primary identifier, because it will be guaranteed to be the And then you say something like this (or that this would remove walking different hierarchies in the previous thread - yes, to a certain point but not completely). css_id is a per-css attribute. How can that be the "primariy" identifier when there can be multiple views? For each userland-visible cgroup, there must be a css_set which points to the css's belonging to it, which may not be at the same level - multiple nodes in the userland visible tree may point to the same css. If you mean that css_id would be the primary identifier for that specific controller's css, why even say that? That's true now and won't ever change. > same. What makes the tree overly flexible, is that you can have multiple > roots, starting in multiple places, with arbitrary topologies downwards. And now you seem to be on the same page again. But then again, you're asserting that incorporating forced co-mounts *now* is a gradual step towards the goal, which is utterly bonkers. I don't know. I just can't understand what you're thinking at all. Thanks. -- tejun _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
