The memory controller supports both hierarchical and non-hierarchicalbehavior which is controlled by use_hierarchy knob (0 by default).The primary motivation for this distinction was an ineffectivenessof hierarchical accounting. This has improved a lot since it wasintroduced.

This schizophrenia makes the code and integration with other controllersmore complicated (e.g. mounting it with fully hierarchical one couldhave an unexpected side effects) for no good reason so it would be goodto make the memory controller behave only hierarchically.

It seems that there is no good reasons for deep cgroup hierarchies whichare not truly hierarchical so we could set the default to 1. This might,however, lead to unexpected regressions when somebody relies on thecurrent default behavior. For example, consider the following setup: Root[cpuset,memory] | A (use_hierarchy=0) / \ B C

All three A, B, C have some tasks and their memory limits. The hierarchyis created only because of the cpuset and its configuration.Say the default is changed. Then a memory pressure in C could influenceboth A and B which wouldn't happen before. The problem might be reallyhard to notice (unexpected slowdown).This configuration could be fixed up easily by reorganization, though: Root | A' (use_hierarchy=1, limit=unlimited, no tasks) /|\ A B C

The problem is that we don't know whether somebody has an use case whichcannot be transformed like that. Therefore this patch starts the slowtransition to hierarchical only memory controller by warning users whoare using flat hierarchies. The warning triggers only if a subgroup ofnon-root group is created with use_hierarchy==0.