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.
|