Re: [PATCH v2] mm/page_alloc: fix memalloc_nocma_{save/restore} APIs

[Joonsoo Kim <js1304@gmail.com>]

2020년 7월 24일 (금) 오전 10:08, Andrew Morton <akpm@linux-foundation.org>님이 작성:
>
> On Thu, 23 Jul 2020 10:49:02 +0900 js1304@gmail.com wrote:
>
> > From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> >
> > Currently, memalloc_nocma_{save/restore} API that prevents CMA area
> > in page allocation is implemented by using current_gfp_context(). However,
> > there are two problems of this implementation.
> >
> > First, this doesn't work for allocation fastpath. In the fastpath,
> > original gfp_mask is used since current_gfp_context() is introduced in
> > order to control reclaim and it is on slowpath. So, CMA area can be
> > allocated through the allocation fastpath even if
> > memalloc_nocma_{save/restore} APIs are used.
>
> Whoops.
>
> > Currently, there is just
> > one user for these APIs and it has a fallback method to prevent actual
> > problem.
>
> Shouldn't the patch remove the fallback method?

It's not just the fallback but it also has its own functionality. So,
we should not remove it.

> > 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.

Thanks.