On Wed, 12 Jul 2023, Yin Fengwei wrote: > On 7/12/23 14:23, Yu Zhao wrote: > > On Wed, Jul 12, 2023 at 12:02 AM Yin Fengwei <fengwei.yin@xxxxxxxxx> wrote: > >> --- a/mm/internal.h > >> +++ b/mm/internal.h > >> @@ -643,7 +643,8 @@ static inline void mlock_vma_folio(struct folio *folio, > >> * still be set while VM_SPECIAL bits are added: so ignore it then. > >> */ > >> if (unlikely((vma->vm_flags & (VM_LOCKED|VM_SPECIAL)) == VM_LOCKED) && > >> - (compound || !folio_test_large(folio))) > >> + (compound || !folio_test_large(folio) || > >> + folio_in_range(folio, vma, vma->vm_start, vma->vm_end))) > >> mlock_folio(folio); > >> } > > > > This can be simplified: > > 1. remove the compound parameter > Yes. There is not difference here for pmd mapping of THPs and pte mappings of THPs > if the only condition need check is whether the folio is within VMA range or not. > > But let me add Huge for confirmation. I'm not sure what it is that you need me to confirm: if the folio fits within the vma, then the folio fits within the vma, pmd-mapped or not. (And I agree with Yu that it's better to drop the folio_test_large() check too.) This idea, of counting the folio as mlocked according to whether the whole folio fits within the vma, does seem a good idea to me: worth pursuing. But whether the implementation adds up and works out, I have not checked. It was always difficult to arrive at a satisfactory compromise in mlocking compound pages: I hope this way does work out. Hugh
