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@I-love.SAKURA.ne.jp ).

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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>