On 04.08.23 08:39, Kasireddy, Vivek wrote:
Hi Alistair, David, Jason,
Right, the "the zero pages are changed into writable pages" in your
above comment just might not apply, because there won't be any
page
replacement (hopefully :) ).
If the page replacement does not happen when there are new writes
to the
area where the hole previously existed, then would we still get an
invalidate
when this happens? Is there any other way to get notified when the
zeroed
page is written to if the invalidate does not get triggered?
What David is saying is that memfd does not use the zero page
optimization for hole punches. Any access to the memory, including
read-only access through hmm_range_fault() will allocate unique
pages. Since there is no zero page and no zero-page replacement there
is no issue with invalidations.
It looks like even with hmm_range_fault(), the invalidate does not get
triggered when the hole is refilled with new pages because of writes.
This is probably because hmm_range_fault() does not fault in any pages
that get invalidated later when writes occur.
hmm_range_fault() returns the current content of the VMAs, or it
faults. If it returns pages then it came from one of these two places.
If your VMA is incoherent with what you are doing then you have
bigger
problems, or maybe you found a bug.
Note it will only fault in pages if HMM_PFN_REQ_FAULT is specified. You
are setting that however you aren't setting HMM_PFN_REQ_WRITE which is
what would trigger a fault to bring in the new pages. Does setting that
fix the issue you are seeing?
No, adding HMM_PFN_REQ_WRITE still doesn't help in fixing the issue.
Although, I do not have THP enabled (or built-in), shmem does not evict
the pages after hole punch as noted in the comment in shmem_fallocate():
if ((u64)unmap_end > (u64)unmap_start)
unmap_mapping_range(mapping, unmap_start,
1 + unmap_end - unmap_start, 0);
shmem_truncate_range(inode, offset, offset + len - 1);
/* No need to unmap again: hole-punching leaves COWed pages */
As a result, the pfn is still valid and the pte is pte_present() and pte_write().
This is the reason why adding in HMM_PFN_REQ_WRITE does not help;
Just to understand your setup: you are definitely using a MAP_SHARED
shmem mapping, and not accidentally a MAP_PRIVATE mapping?
--
Cheers,
David / dhildenb
