Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deprecating the PCOMMIT Instruction

software.intel.com

Post reply on HN
Print view View original

21–26 of 26 posts

Re: Deprecating the PCOMMIT Instruction

#21

Post by eloff »

caf wrote: post #14
eloff wrote: post #2

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_DI…

Not exactly, you still need a cache flush if you want to ensure that your write is persistent.

Sorry, yes I omitted that detail. You do need the cache flush still for each written cache line.

Re: Deprecating the PCOMMIT Instruction

#23

Post by koverstreet »

eloff wrote: post #2

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_DI…

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

Re: Deprecating the PCOMMIT Instruction

#24

Post by moosecombinator »

userbinator wrote: post #18

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 exec…

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.

Re: Deprecating the PCOMMIT Instruction

#25

Post by moosecombinator »

jbb555 wrote: post #22

"Persistence domain". Ugh. This is supposed to be a CPU not some marketing speak showcase.

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.

Re: Deprecating the PCOMMIT Instruction

#26

Post by [deleted] »

eloff wrote: post #2

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_DI…

[deleted]
Post reply on HN