On Wed 24-01-18 13:44:02, David Rientjes wrote: > On Wed, 24 Jan 2018, Michal Hocko wrote: > > > > The current implementation of memory.oom_group is based on top of a > > > selection implementation that is broken in three ways I have listed for > > > months: > > > > This doesn't lead to anywhere. You are not presenting any new arguments > > and you are ignoring feedback you have received so far. We have tried > > really hard. Considering different _independent_ people presented more or > > less consistent view on these points I think you should deeply > > reconsider how you take that feedback. > > > > I've responded to each email providing useful feedback on this patchset. > I agreed with Tejun about not embedding the oom mechanism into > memory.oom_policy. I was trying to avoid having two files in the mem > cgroup v2 filesystem for oom policy and mechanism. I agreed that > delegating the mechanism to the workload would be useful in some cases. > I've solicited feedback on any other opinions on how that can be done > better, but it appears another tunable is the most convenient way of > allowing this behavior to be specified. It is not about convenince. Those two things are simply orthogonal. And that's what I've been saying for quite some time. Dunno, why it has been ignored previously. > As a result, this would remove patch 3/4 from the series. Do you have any > other feedback regarding the remainder of this patch series before I > rebase it? Yes, and I have provided it already. What you are proposing is incomplete at best and needs much better consideration and much more time to settle. > I will address the unfair root mem cgroup vs leaf mem cgroup comparison in > a separate patchset to fix an issue where any user of oom_score_adj on a > system that is not fully containerized gets very unusual, unexpected, and > undocumented results. I will not oppose but as it has been mentioned several times, this is by no means a blocker issue. It can be added on top. Thanks! -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
