At 2022-12-08 15:33:07, "Michal Hocko" <mhocko@xxxxxxxx> wrote: >On Thu 08-12-22 11:46:44, chengkaitao wrote: >> From: chengkaitao <pilgrimtao@xxxxxxxxx> >> >> We created a new interface <memory.oom.protect> for memory, If there is >> the OOM killer under parent memory cgroup, and the memory usage of a >> child cgroup is within its effective oom.protect boundary, the cgroup's >> tasks won't be OOM killed unless there is no unprotected tasks in other >> children cgroups. It draws on the logic of <memory.min/low> in the >> inheritance relationship. >> >> It has the following advantages, >> 1. We have the ability to protect more important processes, when there >> is a memcg's OOM killer. The oom.protect only takes effect local memcg, >> and does not affect the OOM killer of the host. >> 2. Historically, we can often use oom_score_adj to control a group of >> processes, It requires that all processes in the cgroup must have a >> common parent processes, we have to set the common parent process's >> oom_score_adj, before it forks all children processes. So that it is >> very difficult to apply it in other situations. Now oom.protect has no >> such restrictions, we can protect a cgroup of processes more easily. The >> cgroup can keep some memory, even if the OOM killer has to be called. >> >> Signed-off-by: chengkaitao <pilgrimtao@xxxxxxxxx> >> --- >> v2: Modify the formula of the process request memcg protection quota. > >The new formula doesn't really address concerns expressed previously. >Please read my feedback carefully again and follow up with questions if >something is not clear. The previous discussion was quite scattered. Can you help me summarize your concerns again? Let me think about the optimization plan for these problems. -- Thanks for your comment! chengkaitao
