Message ID | 20181013050021.11962-1-pagupta@redhat.com (mailing list archive) |
---|---|
Headers | show |
Series | kvm "fake DAX" device | expand |
On Fri, Oct 12, 2018 at 10:00 PM Pankaj Gupta <pagupta@redhat.com> wrote: > > This patch series has implementation for "fake DAX". > "fake DAX" is fake persistent memory(nvdimm) in guest > which allows to bypass the guest page cache. This also > implements a VIRTIO based asynchronous flush mechanism. Can we stop calling this 'fake DAX', because it isn't 'DAX' and it's starting to confuse people. This enabling is effectively a host-page-cache-passthrough mechanism not DAX. Let's call the whole approach virtio-pmem, and leave DAX out of the name to hopefully prevent people from wondering why some DAX features are disabled with this driver. For example MAP_SYNC is not compatible with this approach. Additional enabling is need to disable MAP_SYNC in the presence of a virtio-pmem device. See the rough proposal here: https://lkml.org/lkml/2018/4/25/756
> > > > This patch series has implementation for "fake DAX". > > "fake DAX" is fake persistent memory(nvdimm) in guest > > which allows to bypass the guest page cache. This also > > implements a VIRTIO based asynchronous flush mechanism. > > Can we stop calling this 'fake DAX', because it isn't 'DAX' and it's > starting to confuse people. This enabling is effectively a > host-page-cache-passthrough mechanism not DAX. Let's call the whole > approach virtio-pmem, and leave DAX out of the name to hopefully > prevent people from wondering why some DAX features are disabled with > this driver. For example MAP_SYNC is not compatible with this > approach. Sure. I got your point. I will use "virtio-pmem" in future. > > Additional enabling is need to disable MAP_SYNC in the presence of a > virtio-pmem device. See the rough proposal here: > > https://lkml.org/lkml/2018/4/25/756 Yes, I will handle disabling of MAP_SYNC for this use-case. Thanks, Pankaj