On Mon, 16 Jul 2018, Michal Hocko wrote: > Well, I didn't really get to your patches yet. The last time I've > checked I had some pretty serious concerns about the consistency of your > proposal. Those might have been fixed in the lastest version of your > patchset I haven't seen. But I still strongly suspect that you are > largerly underestimating the complexity of more generic oom policies > which you are heading to. > I don't believe it's underestimated since it's used. It's perfectly valid the lock an entire hierarchy or individual subtrees into a single policy if that's what is preferred. Any use of a different policy at a subtree root is a conscious decision made by the owner of that subtree. If they prefer to kill the largest process, the largest descendant cgroup, or the largest subtree, it is up to them. All three have valid usecases, the goal is not to lock the entire hierarchy into a single policy: this introduces the ability for users to subvert the selection policy either intentionally or unintentionally because they are using a unified single hierarchy with cgroup v2 and they are using controllers other than mem cgroup. > Considering user API failures from the past (oom_*adj fiasco for > example) suggests that we should start with smaller steps and only > provide a clear and simple API. oom_group is such a simple and > semantically consistent thing which is the reason I am OK with it much > more than your "we can be more generic" approach. I simply do not trust > we can agree on sane and consistent api in a reasonable time. > > And it is quite mind boggling that a simpler approach has been basically > blocked for months because there are some concerns for workloads which > are not really asking for the feature. Sure your usecase might need to > handle root memcg differently. That is a fair point but that shouldn't > really block containers users who can use the proposed solution without > any further changes. If we ever decide to handle root memcg differently > we are free to do so because the oom selection policy is not carved in > stone by any api. > Please respond directly to the patchset which clearly enumerates the problems with the current implementation in -mm. -- 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
