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
