[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201203084616.GY17338@dhcp22.suse.cz>
Date: Thu, 3 Dec 2020 09:46:16 +0100
From: Michal Hocko <mhocko@...e.com>
To: Pavel Tatashin <pasha.tatashin@...een.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
akpm@...ux-foundation.org, vbabka@...e.cz, david@...hat.com,
osalvador@...e.de, dan.j.williams@...el.com, sashal@...nel.org,
tyhicks@...ux.microsoft.com, iamjoonsoo.kim@....com,
mike.kravetz@...cle.com, rostedt@...dmis.org, mingo@...hat.com,
jgg@...pe.ca, peterz@...radead.org, mgorman@...e.de,
willy@...radead.org, rientjes@...gle.com, jhubbard@...dia.com
Subject: Re: [PATCH 2/6] mm/gup: don't pin migrated cma pages in movable zone
On Wed 02-12-20 00:23:26, Pavel Tatashin wrote:
> In order not to fragment CMA the pinned pages are migrated. However,
> they are migrated to ZONE_MOVABLE, which also should not have pinned pages.
>
> Remove __GFP_MOVABLE, so pages can be migrated to zones where pinning
> is allowed.
I was wondering why we do have __GFP_MOVABLE at all. Took a shovel
and... 41b4dc14ee807 says:
: We have well defined scope API to exclude CMA region. Use it rather than
: manipulating gfp_mask manually. With this change, we can now restore
: __GFP_MOVABLE for gfp_mask like as usual migration target allocation. It
: would result in that the ZONE_MOVABLE is also searched by page allocator.
: For hugetlb, gfp_mask is redefined since it has a regular allocation mask
: filter for migration target. __GPF_NOWARN is added to hugetlb gfp_mask
: filter since a new user for gfp_mask filter, gup, want to be silent when
: allocation fails.
This clearly states that the priority was to increase the migration
target success rate rather than bother with the pinning aspect of the
target page. So I believe we have simply ignored/missed the point of the
movable zone guarantees back then and that was a mistake.
> Signed-off-by: Pavel Tatashin <pasha.tatashin@...een.com>
I have to admit I am not really sure about the failure path. The code is
just too convoluted to follow. I presume the pin will fail in that case.
Anyway this wouldn't be anything new in this path. Movable zone
exclusion can make the failure slightly more possible in some setups but
fundamentally nothing new there.
Acked-by: Michal Hocko <mhocko@...e.com>
> ---
> mm/gup.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/gup.c b/mm/gup.c
> index cdb8b9eeb016..3a76c005a3e2 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -1610,7 +1610,7 @@ static long check_and_migrate_cma_pages(struct mm_struct *mm,
> long ret = nr_pages;
> struct migration_target_control mtc = {
> .nid = NUMA_NO_NODE,
> - .gfp_mask = GFP_USER | __GFP_MOVABLE | __GFP_NOWARN,
> + .gfp_mask = GFP_USER | __GFP_NOWARN,
> };
>
> check_again:
> --
> 2.25.1
>
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists