Re: Subtle races between DAX mmap fault and write path
On Mon, Aug 08, 2016 at 12:30:18PM +0000, Boylston, Brian wrote:
I used NVML 1.1 for the measurements. In this version and with the
hardware
that I used, the pmem_persist() flow is:
Please don't use crap like NVML, given that the people behind it don't
seem to understand persistency at all.
Perhaps you mean pmem_msync() here? pmem_msync() calls msync(), but
pmem_persist() does not.
pmem_persist is misnamed then, don't use it.
> At which point
> you've lost most of the advantages using movnt. Ross researches into
> possibilities of allowing more efficient userspace implementation but
> currently there are none.
Apart from the current performance discussion, if the metadata for a file
is already established (file created, space allocated by explicit writes(),
and everything synced), then if I map it and do pmem_memcpy_persist(),
are there any "ongoing" metadata updates that would need to be flushed
(besides timestamps)?
Yes. For example because every write might mean a new space allocating
if using reflinks or a COW file system.