[LSF/MM ATTEND] memory.low hierarchic semantics

[LSF/MM ATTEND] memory.low hierarchic semantics

[Roman Gushchin]

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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>