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

[David Hildenbrand <david@redhat.com>]

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