On Thu, 14 Sep 2017, Michal Hocko wrote: > > It is certainly possible to add oom priorities on top before it is merged, > > but I don't see why it isn't part of the patchset. > > Because the semantic of the priority for non-leaf memcgs is not fully > clear and I would rather have the core of the functionality merged > before this is sorted out. > We can't merge the core of the feature before this is sorted out because then users start to depend on behavior and we must be backwards compatible. We need a full patchset that introduces the new selection heuristic and a way for userspace to control it to either bias or prefer one cgroup over another. The kill-all mechanism is a more orthogonal feature for the cgroup-aware oom killer than oom priorities. I have a usecase for both the cgroup-aware oom killer and its oom priorities from previous versions of this patchset, I assume that Roman does as well, and would like to see it merged bacause there are real-world usecases for it rather than hypothetical usecases that would want to do something different. > > We need it before its > > merged to avoid users playing with /proc/pid/oom_score_adj to prevent any > > killing in the most preferable memcg when they could have simply changed > > the oom priority. > > I am sorry but I do not really understand your concern. Are you > suggesting that users would start oom disable all tasks in a memcg to > give it a higher priority? Even if that was the case why should such an > abuse be a blocker for generic memcg aware oom killer being merged? If users do not have any way to control victim selection because of a shortcoming in the kernel implementation, they will be required to oom disable processes and let that be inherited by children they fork in the memcg hierarchy to protect cgroups that they do not want to be oom killed, regardless of their size. They simply are left with no other alternative if they want to use the cgroup-aware oom killer and/or the kill-all mechanism. -- 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
