Re: [RFC PATCH] memcg: use root_mem_cgroup when css is inherited

On Wed, Aug 24, 2022 at 6:27 PM Michal Hocko [off-list ref] wrote:

On Wed 24-08-22 17:34:42, Zhaoyang Huang wrote:

quoted

On Wed, Aug 24, 2022 at 3:50 PM Michal Hocko [off-list ref] wrote:

quoted

On Wed 24-08-22 10:23:14, Zhaoyang Huang wrote:

quoted

On Tue, Aug 23, 2022 at 7:51 PM Michal Hocko [off-list ref] wrote:

[...]

quoted

quoted

One way to achieve that would be shaping the hierarchy the following way
            root
        /         \
no_memcg[1]      memcg[2]
||||||||         |||||
app_cgroups     app_cgroups

with
no_memcg.subtree_control = ""
memcg.subtree_control = memory

no?

According to my understanding, No as there will be no no_memcg. All
children groups under root would have its cgroup.controllers = memory
as long as root has memory enabled.

Correct

quoted

Under this circumstance, all
descendants group under 'no_memcg' will charge memory to its parent
group.

Correct. And why is that a problem? I thought you main concern was a per
application LRUs. With the above configuration all app_cgroups which do
not require an explicit memory control will share the same (no_memcg)
LRU and they will be aged together.

I can't agree since this indicates the processes want memory free
depending on a specific hierarchy which could have been determined by
other subsys.

I really fail to understand your requirements.

quoted

IMHO, charging the pages which out of explicitly memory
enabled group to root could solve all of the above constraints with no
harm.

This would break the hierarchical property of the controller. So a
strong no no. Consider the following example

       root
        |
        A
controllers="memory"
memory.max = 1G
subtree_control=""
|      |      |
A1     A2     A3

althought A1,2,3 do not have their memory controller enabled explicitly
they are still constrained by the A memcg limit. If you just charge to
the root because it doesn't have memory controller enabled explicitly
then you just evade that constrain. I hope you understand why that is a
problem.

IMO, A1-A3 should be explicitly enabled via echo "+memory" >
A/subtree_control since memory.max has been set. How should AA3
achieve the goal of compete with AA4,A1,A2 for cpu but keep memory out
of control under current policy?
        root
         |
         A
 controllers="memory,cpu"
 memory.max = 1G
 subtree_control="memory,cpu"
 |      |      |
 A1     A2     A3 subtree_control="cpu"
                      |      |
                    AA3   AA4 controllers="cpu"

--
Michal Hocko
SUSE Labs