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

[David Hildenbrand]

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.

(I am 99.9% sure that we can replace fallocate()+MADV_DONTNEED by 
fallocate() for fd-based shared mappings, but that's a different story)

--
Thanks,

David / dhildenb