[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201214141946.GG32193@dhcp22.suse.cz>
Date: Mon, 14 Dec 2020 15:19:46 +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,
linux-doc@...r.kernel.org
Subject: Re: [PATCH v3 5/6] mm/gup: migrate pinned pages out of movable zone
On Fri 11-12-20 15:21:39, Pavel Tatashin wrote:
[...]
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index b593316bff3d..25c0c13ba4b1 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -386,9 +386,14 @@ enum zone_type {
> * likely to succeed, and to locally limit unmovable allocations - e.g.,
> * to increase the number of THP/huge pages. Notable special cases are:
> *
> - * 1. Pinned pages: (long-term) pinning of movable pages might
> - * essentially turn such pages unmovable. Memory offlining might
> - * retry a long time.
> + * 1. Pinned pages: (long-term) pinning of movable pages is avoided
> + * when pages are pinned and faulted, but it is still possible that
> + * address space already has pages in ZONE_MOVABLE at the time when
> + * pages are pinned (i.e. user has touches that memory before
> + * pinning). In such case we try to migrate them to a different zone,
> + * but if migration fails the pages can still end-up pinned in
> + * ZONE_MOVABLE. In such case, memory offlining might retry a long
> + * time and will only succeed once user application unpins pages.
I do agree with others in the thread. This is not really helping out the
current situation much. You should simply fail the pin rather than
pretend all is just fine.
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists