On Fri, Dec 18, 2020 at 8:08 AM Michal Hocko <mhocko@xxxxxxxx> wrote: > > On Fri 18-12-20 07:24:53, Pavel Tatashin wrote: > > On Fri, Dec 18, 2020 at 4:43 AM Michal Hocko <mhocko@xxxxxxxx> wrote: > > > > > > 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. > > > > This is basically current behaviour, after patch 8, we can never pin > > pages in the movable zone, so I will update this comment in that > > patch. > > Then it would be much easier for review to state that the existing > behavior is unchanged and do not update this comment just to remove it > in a later patch. Because this patch should be straightforward change of > the condition which pages to migrate (+some renaming which should be > reasonably easy to follow). Makes sense, I will update this comment correctly right away when the behaviour changes.
