On Thu, Feb 13, 2020 at 02:07:07AM +0000, Li Xinhai wrote: > MPOL_MF_STRICT is used in mbind() for purposes: > (1) MPOL_MF_STRICT is set alone without MPOL_MF_MOVE or MPOL_MF_MOVE_ALL, > to check if there is misplaced page and return -EIO; > (2) MPOL_MF_STRICT is set with MPOL_MF_MOVE or MPOL_MF_MOVE_ALL, to check > if there is misplaced page which is failed to isolate, or page is > success on isolate but failed to move, and return -EIO. > > For non hugepage mapping, (1) and (2) are implemented as expectation. > For hugepage mapping, (1) is not implemented. And in (2), the part about > failed to isolate and report -EIO is not implemented. > > This patch implements the missed parts for hugepage mapping. Benefits > with it applied: > - User space can apply same code logic to handle mbind() on hugepage and > non hugepage mapping; > - Reliably using MPOL_MF_STRICT alone to check whether there is misplaced > page or not when bind policy on address range, especially for address > range which contains both hugepage and non hugepage mapping. > > Analysis of potential impact to existing users: > - If MPOL_MF_STRICT alone was previously used, hugetlb pages not following > the memory policy would not cause an EIO error. After this change, > hugetlb pages are treated like all other pages. If MPOL_MF_STRICT alone > is used and hugetlb pages do not follow memory policy an EIO error will > be returned. > - For users who using MPOL_MF_STRICT with MPOL_MF_MOVE or > MPOL_MF_MOVE_ALL, the semantic about some pages could not be moved will > not be changed by this patch, because failed to isolate and failed to > move have same effects to users, so their existing code will not be > impacted. > > In mbind man page, the note about 'MPOL_MF_STRICT is ignored on huge page > mappings' can be removed after this patch is applied. > > Signed-off-by: Li Xinhai <lixinhai.lxh@xxxxxxxxx> > Cc: Michal Hocko <mhocko@xxxxxxxx> > Cc: Mike Kravetz <mike.kravetz@xxxxxxxxxx> > Cc: Naoya Horiguchi <n-horiguchi@xxxxxxxxxxxxx> > Cc: linux-man <linux-man@xxxxxxxxxxxxxxx> Thanks, Reviewed-by: Naoya Horiguchi <naoya.horiguchi@xxxxxxx>
