Hello! Current semantics of memory.low makes it hard to use in a hierarchy, where some memcg's are more valuable than others. For instance, let's say we have memcgs A, A/B and A/C; A/B should have 10Gb of guaranteed memory, a A/C is expected to use the surplus on the machine. The question is what should we set as the A/memory.low value? A A/memory.low ??? / \ B C B/memory.low = 10G, C/memory.low = 0 If we set it to 10G (the minimum reasonable number), B's memory guarantee will not work until sum of B and C memory consumption will reach 10G. And it might be by far below 10G, which makes no sense. The only case, when it might work, is when there is only one leaf cgroup in the sub-tree. The only other option I see is to set it to 'max'. Then B's memory guarantee will work as expected. But this basically means that all non-leaf memcgs must have memory.low set to 'max', otherwise leaf's memory.low have no meaning. Such approach makes impossible protecting the system from the misbehavior in case of sub-tree delegation. I have no solution for the described problem, but I believe that we should somehow scale the memory pressure on B and C, depending on how much their usage exceeds their guarantees. Another option is to scan only those children memcgs, which are above their guarantees, until the are some (as we do for memory.low in general). It will be very valuable to discuss this problem and try to find a possible approach to it, which will make sense semantically and be acceptable in terms of performance. Thanks! Roman -- 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>
