Michal Hocko wrote: > > But since Michal is still worrying that adding a single synchronization > > point into the OOM path is risky (without showing a real life example > > where lock_killable() in the coldest OOM path hurts), changes made by > > this patch will be enabled only when oom_compat_mode=0 kernel command line > > parameter is specified so that users can test whether their workloads get > > hurt by this patch. > > > Nacked with passion. This is absolutely hideous. First of all there is > absolutely no need for the kernel command line. That is just trying to > dance around the fact that you are not able to argue for the change > and bring reasonable arguments on the table. We definitely do not want > two subtly different modes for the oom handling. Secondly, and repeatedly, > you are squashing multiple changes into a single patch. And finally this > is too big of a hammer for something that even doesn't solve the problem > for PREEMPTIVE kernels which are free to schedule regardless of the > sleep or the reclaim retry you are so passion about. So, where is your version? Offload to a kernel thread like the OOM reaper? Get rid of oom_lock? Just rejecting my proposal makes no progress. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
