PCOMMIT, SFENCE and CLFLUSH

[Mohammed G. Khatib]

Hi all,

Reading the libpmem, it seems that PCOMMIT may not be available in all architectures, which is expected since it has been recently introduced. Is is true to assume that without PCOMMIT durability is not guaranteed? SFENCE guarantees ordering but not durability.

If this is true, it is perhaps worth noting (in bold) somewhere that until PCOMMIT is available, there is no guarantee on durability. Please correct me if I am wrong here.

As for CLFLUSH and CLFLUSHOPT, does anyone know the exact diferences? I know OPT is only optimized...

Thanks!

Mohammed

[Mohammed G. Khatib]

Just copying Andy's response here with my comments:

I thought about having the library refuse to run if PCOMMIT is
unavailable but decided there are valid use cases without PCOMMIT
(like some HW that doesn't require it).  Since I have no way to detect
whether PCOMMIT is required or not, I pushed the that decision up to
the application.  It can call pmem_has_hw_drain() to see if a way to
drain stores in hardware is available and decide to abort out if not.
I documented it in the man page, but your suggestion that it should be
more prominently noted is a good one!

> I do agree with your decision and indeed with ADR feature one can still use the library and do more stuff.

On CLFLUSH versus CLFLUSHOPT, the difference is that CLFLUSH is a
serialized instruction for historical reasons.  So if you have to
flush a range of persistent memory, looping through it and doing
CLFLUSH will mean they happen one after another.  But if you instead
use CLFLUSHOPT and follow the loop with an SFENCE, then you'll get
some parallelism since the CLFLUSHOPT is weakly-ordered.  That's the
optimization referred to by the "OPT in the opcode name.

> CLFLUSHOPT requires no strict serialization of store operations. Thanks for the clarification!