On Fri, Sep 9, 2016 at 1:55 AM, Xiao Guangrong
<guangrong.xiao@xxxxxxxxxxxxxxx> wrote:
[..]
Whether a persistent memory mapping requires an msync/fsync is a
filesystem specific question. This mincore proposal is separate from
that. Consider device-DAX for volatile memory or mincore() called on
an anonymous memory range. In those cases persistence and filesystem
metadata are not in the picture, but it would still be useful for
userspace to know "is there page cache backing this mapping?" or "what
is the TLB geometry of this mapping?".
I got a question about msync/fsync which is beyond the topic of this thread
:)
Whether msync/fsync can make data persistent depends on ADR feature on
memory
controller, if it exists everything works well, otherwise, we need to have
another
interface that is why 'Flush hint table' in ACPI comes in. 'Flush hint
table' is
particularly useful for nvdimm virtualization if we use normal memory to
emulate
nvdimm with data persistent characteristic (the data will be flushed to a
persistent storage, e.g, disk).
Does current PMEM programming model fully supports 'Flush hint table'? Is
userspace allowed to use these addresses?
If you publish flush hint addresses in the virtual NFIT the guest VM
will write to them whenever a REQ_FLUSH or REQ_FUA request is sent to
the virtual /dev/pmemX device. Yes, seems straightforward to take a
VM exit on those events and flush simulated pmem to persistent
storage.