> This is not the first time we have changed or obsoleted tunables in > /proc/sys/vm. If a startup tool really is really bailing out depending on > whether echo 1 > /proc/sys/vm/oom_kill_allocating_task succeeds, it should > be fixed regardless because you're not protecting anything by doing that > > since you can't predict what task is allocating memory at the time of oom. > Those same startup tools will need to disable /proc/sys/vm/oom_dump_tasks > if we are to remove the consolidation into oom_kill_quick and maintain two > seperate VM sysctls that are always used together by the same users. > > Nobody can even cite a single example of oom_kill_allocating_task being > used in practice, yet we want to unnecessarily maintain these two seperate > sysctls forever because it's possible that a buggy startup tool cares > about the return value of enabling it? > > > Others had other objections, iirc. > > > > I'm all ears. Complain. Many people reviewed these patches, but following four patches got no ack. oom-badness-heuristic-rewrite.patch oom-default-to-killing-current-for-pagefault-ooms.patch oom-deprecate-oom_adj-tunable.patch oom-replace-sysctls-with-quick-mode.patch IIRC, alan and nick and I NAKed such patch. everybody explained the reason. We don't hope join loudly voice contest nor help to making flame. but it doesn't mean explicit ack. Andrew, If you really really really hope to merge these, I'm not againt it anymore. but please put following remark explicitely into the patches. Nacked-by: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxxxxxxx> -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>