On Mon, Jan 02, 2017 at 02:35:36AM +0000, Elliott, Robert (Persistent Memory) wrote: > > -----Original Message----- > > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > > ow...@vger.kernel.org] On Behalf Of Al Viro > > Sent: Friday, December 30, 2016 8:26 PM > > Subject: [RFC] memcpy_nocache() and memcpy_writethrough() > > > ... > > Why does pmem need writethrough warranties, anyway? > > Using either > * nontemporal store instructions; or > * following regular store instructions with a sequence of cache flush > and store fence instructions (e.g., clflushopt or clwb + sfence) > > ensures that write data has reached an "ADR-safe zone" that the system > promises will be persistent even if there is a surprise power loss or > a CPU suffers from an error that isn't totally catastrophic (e.g., the > CPU getting disconnected from the SDRAM will always lose data on an > NVDIMM-N).
Wait a sec... In which places do you need sfence in all that? movnt* itself can be reordered, right? So using that for copying and storing the pointer afterwards would still need sfence inbetween, unless I'm seriously misunderstanding the situation... > Newly written data becomes globally visible before it becomes ADR-safe. > This means software could act on the new data before a power loss, then > see the old data reappear after the power loss - not good. Software > needs to understand that any data in the process of being written is > indeterminate until the persistence guarantee is met. The BTT shows > one way that software can avoid that problem. Joy. What happens in terms of latency? I.e. how much of a stall does clwb inflict?
