Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <1595468942-29687-1-git-send-email-iamjoonsoo.kim@lge.com> <20200723180814.acde28b92ce6adc785a79120@linux-foundation.org>
In-Reply-To: <20200723180814.acde28b92ce6adc785a79120@linux-foundation.org>
From:   Joonsoo Kim <js1304@gmail.com>
Date:   Fri, 24 Jul 2020 11:23:52 +0900
Message-ID: <CAAmzW4N9Y4W7CHenWA=TYu9tttgpYR=ZN+ky1vmXPgUJcjitAw@mail.gmail.com>
Subject: Re: [PATCH v2] mm/page_alloc: fix memalloc_nocma_{save/restore} APIs
To:     Andrew Morton <akpm@linux-foundation.org>
Cc:     Linux Memory Management List <linux-mm@kvack.org>,
        LKML <linux-kernel@vger.kernel.org>, kernel-team@lge.com,
        Vlastimil Babka <vbabka@suse.cz>,
        Christoph Hellwig <hch@infradead.org>,
        Roman Gushchin <guro@fb.com>,
        Mike Kravetz <mike.kravetz@oracle.com>,
        Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
        Michal Hocko <mhocko@suse.com>,
        "Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>,
        Joonsoo Kim <iamjoonsoo.kim@lge.com>, stable@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

2020=EB=85=84 7=EC=9B=94 24=EC=9D=BC (=EA=B8=88) =EC=98=A4=EC=A0=84 10:08, =
Andrew Morton <akpm@linux-foundation.org>=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=
=B1:
>
> 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(). Howev=
er,
> > 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 effe=
ct
> > 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. Perha=
p,
performance would be improved due to reduced retry and more available memor=
y
(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.