2020년 7월 24일 (금) 오후 12:14, Andrew Morton akpm@linux-foundation.org님이 작성:
On Fri, 24 Jul 2020 12:04:02 +0900 Joonsoo Kim js1304@gmail.com wrote:
2020년 7월 24일 (금) 오전 11:36, Andrew Morton akpm@linux-foundation.org님이 작성:
On Fri, 24 Jul 2020 11:23:52 +0900 Joonsoo Kim js1304@gmail.com wrote:
Second, clearing __GFP_MOVABLE in current_gfp_context() has a side effect to exclude the memory on the ZONE_MOVABLE for allocation target.
More whoops.
Could we please have a description of the end-user-visible effects of this change? Very much needed when proposing a -stable backport, I think.
In fact, there is no noticeable end-user-visible effect since the fallback would cover the problematic case. It's mentioned in the commit description. Perhap, performance would be improved due to reduced retry and more available memory (we can use ZONE_MOVABLE with this patch) but it would be neglectable.
d7fefcc8de9147c is over a year old. Why did we only just discover this? This makes one wonder how serious those end-user-visible effects are?
As mentioned above, there is no visible problem to the end-user.
OK, thanks. In that case, I don't believe that a stable backport is appropriate?
(Documentation/process/stable-kernel-rules.rst)
Thanks for the pointer!
Hmm... I'm not sure the correct way to handle this patch. I thought that memalloc_nocma_{save,restore} is an API that is callable from the module. If it is true, it's better to regard this patch as the stable candidate since out-of-tree modules could use it without the fallback and it would cause a problem. But, yes, there is no visible problem to the end-user, at least, within the mainline so it is possibly not a stable candidate.
Please share your opinion about this situation.
We tend not to care much about out-of-tree modules. I don't think a theoretical concern for out-of-tree code justifies risking the stability of -stable kernels.
Okay. It's appreciated if you remove the stable tag. Or, I will send it again without the stable tag.
Thanks.