On Wed, 17 Jan 2018, Michal Hocko wrote: > Absolutely agreed! And moreover, there are not all that many ways what > to do as an action. You just kill a logical entity - be it a process or > a logical group of processes. But you have way too many policies how > to select that entity. Do you want to chose the youngest process/group > because all the older ones have been computing real stuff and you would > lose days of your cpu time? Or should those who pay more should be > protected (aka give them static priorities), or you name it... > That's an argument for making the interface extensible, yes. > I am sorry, I still didn't grasp the full semantic of the proposed > soluton but the mere fact it is starting by conflating selection and the > action is a no go and a wrong API. This is why I've said that what you > (David) outlined yesterday is probably going to suffer from a much > longer discussion and most likely to be not acceptable. Your patchset > proves me correct... I'm very happy to change the API if there are better suggestions. That may end up just being an memory.oom_policy file, as this implements, and separating out a new memory.oom_action that isn't a boolean value to either do a full group kill or only a single process. Or it could be what I suggested in my mail to Tejun, such as "hierarchy killall" written to memory.oom_policy, which would specify a single policy and then an optional mechanism. With my proposed patchset, there would then be three policies: "none", "cgroup", and "tree" and one possible optional mechanism: "killall". -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
