Dan Williams <dan.j.williams(a)intel.com> writes:
> [ adding Jeff directly since he has also been looking at
> infrastructure to track when MAP_SYNC should be disabled ]
> On Wed, Apr 25, 2018 at 7:21 AM, Dan Williams <dan.j.williams(a)intel.com>
>> On Wed, Apr 25, 2018 at 4:24 AM, Pankaj Gupta <pagupta(a)redhat.com> wrote:
>>> This patch adds virtio-pmem driver for KVM
>> Minor nit, please expand your changelog line wrapping to 72 columns.
>>> Guest reads the persistent memory range
>>> information from Qemu over VIRTIO and registers
>>> it on nvdimm_bus. It also creates a nd_region
>>> object with the persistent memory range
>>> information so that existing 'nvdimm/pmem'
>>> driver can reserve this into system memory map.
>>> This way 'virtio-pmem' driver uses existing
>>> functionality of pmem driver to register persistent
>>> memory compatible for DAX capable filesystems.
>> We need some additional enabling to disable MAP_SYNC for this
enable to disable... I like it! ;-)
>> configuration. In other words, if fsync() is required then we must
>> disable the MAP_SYNC optimization. I think this should be a struct
>> dax_device property looked up at mmap time in each MAP_SYNC capable
>> ->mmap() file operation implementation.
I understand you mean we want to disable 'MAP_SYNC' optimization as
we are relying on additional fsync. You mean if we add a property/flag
in dax_device struct and its set, disable 'MAP_SYNC' accordingly during
mmap time for corresponding filesystems?
Ideally, qemu (seabios?) would advertise a platform capabilities
sub-table that doesn't fill in the flush bits.
Could you please elaborate on this, how its related to disabling
MAP_SYNC? We are not doing entire nvdimm device emulation.