On Thu, Dec 3, 2020 at 3:46 AM Michal Hocko <mhocko@xxxxxxxx> wrote: > > 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@xxxxxxxxxx> > > 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. I've been trying to keep this series simple for easier backport, and not to introduce new changes beside increasing the scope of pages which are not allowed to be pinned. This area, however, requires some inspection and fixes, something that Jason also mentioned in another patch. > Acked-by: Michal Hocko <mhocko@xxxxxxxx> Thank you, Pasha
