qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Purpose of memory-backend-file.discard-data


From: Michal Privoznik
Subject: Re: [Qemu-devel] Purpose of memory-backend-file.discard-data
Date: Tue, 17 Apr 2018 10:23:18 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

On 04/16/2018 07:59 PM, Eduardo Habkost wrote:
> (CCing Zack Cornelius)
> 
> On Fri, Apr 13, 2018 at 08:21:26AM +0200, Michal Privoznik wrote:
>> Eduardo et al,
>>
>> I'm looking at 11ae6ed8affdd131e and I wanted to implement libvirt
>> support for that. But more I look at it less I understand it. My
>> understanding it is an optimization (although not very effective one
>> since madvise() is/should be immediately followed by munmap()). So any
>> application that is trying to keep track of guest memory  can stop doing
>> so as soon as it sees munmap(). Or does the optimization lies in fact
>> that madvise() is called sooner and thus the app can stop caring
>> slightly sooner?
> 
> munmap() or close() are not enough: it would still make the host
> kernel unnecessarily write data to backing storage.

Something like sync()? I though that mem access is always synchronous.
Or perhaps I don't understand why is kernel still touching data after
munmap().

>  The point of
> the madvise() call is to tell the kernel that data can be
> destroyed instead of being written back.
> 
> The original use case is described by Zack here:
> https://www.mail-archive.com/address@hidden/msg473538.html
> 
> 
>>
>> Also, I don't quite understand why is this configurable. What's the harm
>> in turning it on by default? Yesterday I've posted some patches to
>> libvirt list [1] (although I have to admit I am still not fully
>> convinced about the design) and they implement just this - whenever qemu
>> supports the feature libvirt turns it on.S
> 
> The option can destroy the data on the backing file, so QEMU can't enable it 
> by
> default.  libvirt can enable it as long as it knows it can destroy the data on
> the backing file.

Destroy data? Oh, okay then. I rather make it configurable. Although I'm
not quite sure about XML design yet.

Michal



reply via email to

[Prev in Thread] Current Thread [Next in Thread]