On Thu, Apr 06, 2017 at 06:31:17PM +0800, Haozhong Zhang wrote: > On 04/06/17 10:43 +0100, Stefan Hajnoczi wrote: > > On Fri, Mar 31, 2017 at 04:41:43PM +0800, Haozhong Zhang wrote: > > We should think about the optimal way of implementing Flush Hint > > Addresses in QEMU. But if there is no reasonable way to implement them > > then I think it's better *not* to implement them, just like the Block > > Window feature which is also not virtualization-friendly. Users who > > want a block device can use virtio-blk. I don't think NVDIMM Block > > Window can achieve better performance than virtio-blk under > > virtualization (although I'm happy to be proven wrong). > > > > Some ideas for a faster implementation: > > > > 1. Use memory_region_clear_global_locking() to avoid taking the QEMU > > global mutex. Little synchronization is necessary as long as the > > NVDIMM device isn't hot unplugged (not yet supported anyway). > > > > ACPI spec does not say it allows or disallows multiple writes to the > same flush hint address in parallel. If it can, I think we can remove > the global locking requirement for the MMIO memory region of the flush > hint address of vNVDIMM.
The Linux code tries to spread the writes but two CPUs can write to the same address sometimes. It doesn't matter if two vcpus access the same address because QEMU just invokes fsync(2). The host kernel has synchronization to make the fsync safe. Stefan
signature.asc
Description: PGP signature
