Re: [PATCH v5 24/26] mm/pagemap: Recognize uffd-wp bit for shmem/hugetlbfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jul 19, 2021 at 05:23:14PM +0000, Tiberiu Georgescu wrote:
> > What we're clear is we know it's uffd wr-protected, so maybe setting PM_UFFD_WP
> > is still the simplest?
> 
> That's right, but if we were to require any of the differentiations above, how
> does keeping another bit on the special pte sound to you? One to signal the location on swap or otherwise (none or zapped).

I don't know how to do it even with an extra bit in the pte.  The thing is we
need some mechanism to trigger the tweak of that bit in the pte when switching
from "present" to "swapped out", while I don't see how that could be done.

Consider when page reclaim happens, we'll unmap and zap the ptes first before
swapping the pages out, then when we do the pageout() we've already released
the rmap so no way to figure out which pte to tweak, afaiu.  It also looks
complicated just for maintaining this information.

> 
> Is there any other clearer way to do it? We wouldn't want to overload the
> special pte unnecessarily.

I feel like the solution you proposed in the other patch for soft dirty might
work.  It's just that it seems heavier, especially because we'll try to look up
the page cache for every single pte_none() (and after this patch including the
swap special pte) even if the page is never accessed.

I expect it will regress the case of a normal soft-dirty user when the memory
is sparsely used, because there'll be plenty of page cache look up operations
that are destined to be useless.

I'm also curious what would be the real use to have an accurate PM_SWAP
accounting.  To me current implementation may not provide accurate value but
should be good enough for most cases.  However not sure whether it's also true
for your use case.

Thanks,

-- 
Peter Xu





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux