Michal Hocko wrote:
> JFYI, I plan to repost the series early next week after I review all the
> pieces again properly with a clean head. If some parts are not sound or
> completely unacceptable in principle then let me know of course.
I don't think we can apply this series.
[PATCH 1/6] is unreliable and will be dropped.
[PATCH 2/6] would be OK as a clean up.
[PATCH 3/6] will change user visible part. We deprecated /proc/pid/oom_adj
in Aug 2010 (nearly 6 years ago) by commit 51b1bd2ace1595b7 ("oom: deprecate
oom_adj tunable") but we still preserve that behavior, don't we? I think
[PATCH 3/6] will need 5 to 10 years of get-acquainted period in order to
make sure that no end users will depend on current behavior. This is not
something we can change now.
[PATCH 4/6] is unsafe as Vladimir commented.
[PATCH 5/6] will also change user visible part. We need get-acquainted period.
This is not something we can change now.
[PATCH 6/6] seems to be unsafe as I commented on a different thread
( http://lkml.kernel.org/r/201605282122.HAD09894.SFOFHtOVJLOQMF@xxxxxxxxxxxxxxxxxxx ).
You are trying to make the OOM killer as per mm_struct operation. But
I think we need to tolerate the OOM killer as per signal_struct operation.
--
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>