Re: [PATCH v3 02/12] softmmu/physmem: Fix ram_block_discard_range() to handle shared anonymous memory

[Peter Xu]

On Thu, Mar 11, 2021 at 06:15:15PM +0100, David Hildenbrand wrote:
> On 11.03.21 18:11, Peter Xu wrote:
> > On Thu, Mar 11, 2021 at 05:45:46PM +0100, David Hildenbrand wrote:
> > > On 11.03.21 17:39, Dr. David Alan Gilbert wrote:
> > > > * David Hildenbrand (david@redhat.com) wrote:
> > > > > We can create shared anonymous memory via
> > > > >       "-object memory-backend-ram,share=on,..."
> > > > > which is, for example, required by PVRDMA for mremap() to work.
> > > > > 
> > > > > Shared anonymous memory is weird, though. Instead of MADV_DONTNEED, we
> > > > > have to use MADV_REMOVE. MADV_DONTNEED fails silently and does 
> > > > > nothing.
> > > > 
> > > > OK, I wonder how stable these rules are; is it defined anywhere that
> > > > it's required?
> > > > 
> > > 
> > > I had a look at the Linux implementation: it's essentially shmem ... but 
> > > we
> > > don't have an fd exposed, so we cannot use fallocate() ... :)
> > > 
> > > MADV_REMOVE documents (man):
> > > 
> > > "In the initial implementation, only tmpfs(5) was supported MADV_REMOVE; 
> > > but
> > > since Linux 3.5, any filesystem which supports the fallocate(2)
> > > FALLOC_FL_PUNCH_HOLE mode also supports MADV_REMOVE."
> > 
> > Hmm, I see that MADV_DONTNEED will still tear down all mappings even for
> > anonymous shmem.. what did I miss?
> 
> Where did you see that?

I see madvise_dontneed_free() calls zap_page_range().

> 
> > 
> 
> MADV_DONTNEED only invalidates private copies in the pagecache. It's
> essentially useless for any kind of shared mappings.

Since it's about zapping page tables, then I don't understand why it won't work
for shmem..

-- 
Peter Xu