This is a nice improvement. Now instead of having sfence/pcommit/sfence to flush writes to nvram, you would use just an sfence to ensure ordering with subsequent stores (e.g. a store that publishes the written data.)
Its analogous to fysnc() to ensure data reaches the disk in a way that survives power failure. This is like just treating all writes as fsynced and not needing to worry about fsync at all, like with O_DIRECT writes.
It's a lie that you don't need fsync with O_DIRECT - writes could still be in the hard drive's write buffer, or the filesystem could have metadata updates that haven't been written yet (e.g. unwritten extents that need to be marked as written).
Kernel direct access to Xpoint and similar DIMMs. Potentially applications via mmap. You'd probably write a simple assembly function for it and invoke that from a language that can call assembly routines.
Obvious applications are filesystems and databases.
It's very rare that an instruction gets removed; the few instances that I can think of are XBTS/IBTS on the very first stepping of the 386, and the CMPXCHG on early 486s that occupied the same opcode briefly. Do any CPUs have this instruction?
It looks like the encoding of PCOMMIT (+66 0F AE/7) is basically the same as CLFLUSH except with a +66 prefix, so if a CPU doesn't know about PCOMMIT it'll probably try to execute it as a CLFLUSH with an ignored prefix.
But hopefully this "deprecated" information stays around, if for nothing other than "archaeological" purposes:
Author here. The PCOMMIT encoding you mention produces an undefined opcode fault on all existing CPUs (written as #UD in the specs). Since no CPU has shipped supporting PCOMMIT, this gives us high confidence that no code containing PCOMMIT is currently in-use or it would be producing #UD faults. Since the need for PCOMMIT has gone away, that fact allowed us to remove the instruction before it created legacy code we'd be signed up to support forever.
I love your examples of other removals -- didn't know about those.
Ouch -- accused of marketing speak. That one stings.
I had been using the term "power-fail safe domain" to talk about the line a store crosses where it is then persistent in the face of power failures. But that led people to think power failure was the only event considered so we started saying "persistence domain." I'm certainly open to suggestions on terminology.
25 comments
[ 3.9 ms ] story [ 61.9 ms ] threadIts analogous to fysnc() to ensure data reaches the disk in a way that survives power failure. This is like just treating all writes as fsynced and not needing to worry about fsync at all, like with O_DIRECT writes.
("Deprecating pcommit" means that persistent memory is simpler to use; persistent memory itself is not deprecated.)
Obvious applications are filesystems and databases.
It looks like the encoding of PCOMMIT (+66 0F AE/7) is basically the same as CLFLUSH except with a +66 prefix, so if a CPU doesn't know about PCOMMIT it'll probably try to execute it as a CLFLUSH with an ignored prefix.
But hopefully this "deprecated" information stays around, if for nothing other than "archaeological" purposes:
http://www.os2museum.com/wp/curious-instructions/
I love your examples of other removals -- didn't know about those.
I had been using the term "power-fail safe domain" to talk about the line a store crosses where it is then persistent in the face of power failures. But that led people to think power failure was the only event considered so we started saying "persistence domain." I'm certainly open to suggestions on terminology.