On Sun, Apr 21, 2013 at 9:24 PM, Tejun Heo <tj@xxxxxxxxxx> wrote: > Hey, Michel. > >> I don't remember exactly when you left - during the session I >> expressed to Michal that while I think his proposal is an improvement >> over the current situation, I think his handling of internal nodes is >> confus(ed/ing). > > I think I stayed until near the end of the hierarchy discussion and > yeap I heard you saying that. All right. Too bad you had to leave - I think this is a discussion we really need to have, so it would have been the perfect occasion. >>> > Now, let's consider the following hierarchy just to be sure. Let's >>> > assume that A itself doesn't have any tasks for simplicity. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> > >>> > A (h:16G s:4G) >>> > / \ >>> > / \ >>> > B (h:7G s:5G) C (h:7G s:5G) >>> > >>> > For hardlimit, it is clear that A's limit won't do anything. >> >> One thing some people worry about is that B and C's configuration >> might be under a different administrator's control than A's. That is, >> we could have a situation where the machine's sysadmin set up A for >> someone else to play with, and that other person set up B and C within >> his cgroup. In this scenario, one of the issues has to be how do we >> prevent B and C's configuration settings from reserving (or protecting >> from reclaim) more memory than the machine's admin intended when he >> configured A. > > Cgroup doesn't and will not support delegation of subtrees to > different security domains. Please refer to the following thread. > > http://thread.gmane.org/gmane.linux.kernel.cgroups/6638 Ah, good. This is news to me. To be clear, I don't care much for the delegation scenario myself, but it's always been mentioned as the reason I couldn't get what I want when we've talked about hierarchical soft limit behavior in the past. If the decision not to have subtree delegation sticks, I am perfectly happy with your proposal. > And I don't even get the delegation argument. Isn't that already > covered by hardlimit? Sure, reclaimer won't look at it but if you > don't trust a cgroup it of course will be put under certain hardlimit > from parent and smacked when it misbehaves. Hardlimit of course > should have priority over allocation guarantee and the system wouldn't > be in jeopardy due to a delegated cgroup misbehaving. If each knob is > given a clear meaning, these things should come naturally. You just > need a sane pecking order among the controls. It almost feels surreal > that this is suggested as a rationale for creating this chimera of a > knob. What the hell is going on here? People often overcommit the cgroup hard limits so that one cgroup can make use of a larger share of the machine when the other cgroups are idle. This works well only if you can depend on soft limits to steer reclaim when the other cgroups get active again. -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>