Re: folio mapcount

["Kirill A. Shutemov" <kirill@shutemov.name>]

On Thu, Dec 16, 2021 at 01:56:57PM +0000, Matthew Wilcox wrote:
> > Okay, so you will have mapcount == 2 or 3 for mprotect case above, not
> > 512. But it doesn't help with answering question if the page can be
> > re-used. You would need to do rmap walk to get the answer.
> > 
> > Note also that VMA lifecycle is different from page lifecycle:
> > MADV_DONTNEED removes mapping, but leaves VMA intact. Who would decrement
> > mapcount here?
> 
> I think page_remove_rmap() does when called from zap_huge_pmd().
> The tricky part is handling partial DONTNEED calls.  eg we could have
> a 2MB page (if we're talking about shmem, it could even be mapped
> askew), MADV_DONTNEED the first 512KB, then MADV_DONTNEED the last
> 512KB, then finally MADV_DONTNEED the middle 1MB and only at the third
> call should the mapcount be decremented.
> 
> So a zap call has to check all the PTE/PMD entries in the range of the
> (folio intersect vma) to be sure that there are no more references to
> a part of this folio.  It might not be terribly fast, but it probably
> won't be noticable compared to all the other costs of doing a munmap().

It's not only the area around unmapped. The rest of the page can be
anywhere in the address space, thanks to mremap(2).

I think it would require full rmap, but I'm not sure. Or some very special
tricks on mremap() or vma split. Looks like suffling complexity around,
not reducing it.

-- 
 Kirill A. Shutemov