Re: [RFC PATCH v2 3/3] mm: mlock: update mlock_pte_range to handle large folio

["Yin, Fengwei" <fengwei.yin@intel.com>]

On 7/15/2023 2:06 PM, Yu Zhao wrote:
> There is a problem here that I didn't have the time to elaborate: we
> can't mlock() a folio that is within the range but not fully mapped
> because this folio can be on the deferred split queue. When the split
> happens, those unmapped folios (not mapped by this vma but are mapped
> into other vmas) will be stranded on the unevictable lru.
This should be fine unless I missed something. During large folio split,
the unmap_folio() will be migrate(anon)/unmap(file) folio. Folio will be
munlocked in unmap_folio(). So the head/tail pages will be evictable always.

> 
> For that matter, we can't mlock any large folios that are being
> shared, unless you want to overengineer it by checking whether all
> sharing vmas are also mlocked -- mlock is cleared during fork. So the
> condition for mlocking large anon folios is 1) within range 2) fully
> mapped 3) not shared (mapcount is 1). The final patch should look like
> something like this:
> 
> -  if (folio_test_large(folio))
> +  if (folio_pfn(folio) != pte_pfn(ptent))
> +    continue;
> +  if (!the_aforementioned_condition())
> 
> There is another corner case I forgot to mention: for example, what if
> a folio spans two (the only two) adjacent mlocked vmas? No need to
> worry about this since it's not worth optimizing.
Yes. The behavior will be related with whether the folio is mlocked or not.
But the worst case is the folio is split and each page is mlocked during
next scan again.


Regards
Yin, Fengwei