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

[David Hildenbrand]

On 11.03.21 18:15, 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?
>
> >
>
> MADV_DONTNEED only invalidates private copies in the pagecache. It's
> essentially useless for any kind of shared mappings.


And to clarify, I think what you see is that the mapping gets torn down, 
but not the backend storage released/freed.

Removing the backend storage (MADV_REMOVE/fallocate()) will implicitly 
tear down the mapping from what I can tell (and what my experiments show).

--
Thanks,

David / dhildenb