Re: [RFC] memcpy_nocache() and memcpy_writethrough()

From	Al Viro <viro@ZenIV.linux.org.uk>
Newsgroups	linux.kernel
Subject	Re: [RFC] memcpy_nocache() and memcpy_writethrough()
Date	2017-01-02 06:10 +0100
Message-ID	<sV32F-1Sa-1@gated-at.bofh.it> (permalink)
References	(5 earlier) <sTNCF-1FX-19@gated-at.bofh.it> <sTWwi-7tY-5@gated-at.bofh.it> <sTXsl-84M-9@gated-at.bofh.it> <sUhAK-5fV-7@gated-at.bofh.it> <sV0Hv-9w-13@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Mon, Jan 02, 2017 at 02:35:36AM +0000, Elliott, Robert (Persistent Memory) wrote:
> > -----Original Message-----
> > From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> > owner@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?

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: [PATCH v2 1/3] introduce memcpy_nocache() Al Viro <viro@ZenIV.linux.org.uk> - 2016-12-29 00:50 +0100
  Re: [PATCH v2 1/3] introduce memcpy_nocache() Dan Williams <dan.j.williams@intel.com> - 2016-12-29 19:30 +0100
    Re: [PATCH v2 1/3] introduce memcpy_nocache() Al Viro <viro@ZenIV.linux.org.uk> - 2016-12-30 05:00 +0100
      Re: [PATCH v2 1/3] introduce memcpy_nocache() Dan Williams <dan.j.williams@intel.com> - 2016-12-30 06:00 +0100
        [RFC] memcpy_nocache() and memcpy_writethrough() Al Viro <viro@ZenIV.linux.org.uk> - 2016-12-31 03:30 +0100
          RE: [RFC] memcpy_nocache() and memcpy_writethrough() "Elliott, Robert (Persistent Memory)" <elliott@hpe.com> - 2017-01-02 03:40 +0100
            Re: [RFC] memcpy_nocache() and memcpy_writethrough() Al Viro <viro@ZenIV.linux.org.uk> - 2017-01-02 06:10 +0100

csiph-web