On Fri, Aug 11, 2017 at 05:44:55PM +0100, Daniel P. Berrange wrote: > On Fri, Aug 11, 2017 at 01:33:00PM -0300, Eduardo Habkost wrote: > > CCing Zack Cornelius. > > > > On Wed, Jun 14, 2017 at 05:29:55PM -0300, Eduardo Habkost wrote: > > > This series adds a new "persistent" option to > > > memory-backend-file. The new option it will be useful if > > > somebody is sharing RAM contents on a file using share=on, but > > > don't need it to be flushed to disk when QEMU exits. > > > > > > Internally, it will trigger a madvise(MADV_REMOVE) or > > > fallocate(FALLOC_FL_PUNCH_HOLE) call when the memory backend is > > > destroyed. > > > > > > To make we actually trigger the new code when QEMU exits, the > > > first patch in the series ensures we destroy all user-created > > > objects when exiting QEMU. > > > > So, before sending a new version of this, we need to clarify one > > thing: why exactly unlink()+close() wouldn't be enough to avoid > > having data unnecessarily flushed to the backing store and make > > the new option unnecessary? > > If the backend file is shared between processes, unlinking > it feels bad - you're assuming no /future/ process wants to > attach to the file. Also if QEMU aborts for any reason, the > cleanup code is never going to run
If mem-path is a directory, QEMU will create a file, open() it and unlink() it immediately. This solves the problem of not running the cleanup code when QEMU aborts (which is not solved by the madvise() method). > > > I would expect close() to not write any data unnecessarily if > > there are no remaining references to the file. Why/when this is > > not the case? > > Isn't the unlink() delayed until such time as *all* open handles > on that file are closed. If so, it seems that if 2 processes > have the file open, and one closes it, it is still valid for the > kernel to want to flush data out to the backing store if it needs > to free up working memory consumed by i/o cache. > > If this wasn't the case, then one process could write 20 GB of data, > unlink + close the file, and that 20 GB would never be able to be > purge from I/O cache for as long as another process had that FD > open. That would be pretty bad denial of sevice for memory management > system. I'm assuming QEMU is the only process opening the file. Are there use cases where 1) there's a need for another process to the keep the file open; but 2) there's no need for the data on the file to be kept? -- Eduardo
