[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201218094324.GT32193@dhcp22.suse.cz>
Date: Fri, 18 Dec 2020 10:43:24 +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, ira.weiny@...el.com,
linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v4 05/10] mm/gup: migrate pinned pages out of movable zone
On Thu 17-12-20 13:52:38, Pavel Tatashin wrote:
> + * 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 still dislike this. Pinning can fail so there shouldn't be any reasons
to break MOVABLE constrain for something that can be handled. If
anything there should be a very good reasoning behind this decision
documented.
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists