From: Al Viro <viro@ZenIV.linux.org.uk>
To: "Elliott, Robert (Persistent Memory)" <elliott@hpe.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
Boaz Harrosh <boaz@plexistor.com>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@ml01.01.org>,
"Moreno, Oliver" <oliver.moreno@hpe.com>,
"x86@kernel.org" <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
"boylston@burromesa.net" <boylston@burromesa.net>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [RFC] memcpy_nocache() and memcpy_writethrough()
Date: Mon, 2 Jan 2017 05:09:27 +0000 [thread overview]
Message-ID: <20170102050927.GY1555@ZenIV.linux.org.uk> (raw)
In-Reply-To: <DF4PR84MB016972BE1CA018A9AC4BE592AB6F0@DF4PR84MB0169.NAMPRD84.PROD.OUTLOOK.COM>
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?
next prev parent reply other threads:[~2017-01-02 5:09 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-26 15:50 [PATCH v2 0/3] use nocache copy in copy_from_iter_nocache() Brian Boylston
2016-10-26 15:50 ` [PATCH v2 1/3] introduce memcpy_nocache() Brian Boylston
2016-10-26 19:30 ` Thomas Gleixner
2016-10-28 1:52 ` Boylston, Brian
2016-10-26 19:51 ` Boaz Harrosh
2016-10-28 1:54 ` Boylston, Brian
2016-11-01 14:25 ` Boaz Harrosh
2016-12-28 23:43 ` Al Viro
2016-12-29 18:23 ` Dan Williams
2016-12-30 3:52 ` Al Viro
2016-12-30 4:56 ` Dan Williams
2016-12-31 2:25 ` [RFC] memcpy_nocache() and memcpy_writethrough() Al Viro
2017-01-02 2:35 ` Elliott, Robert (Persistent Memory)
2017-01-02 5:09 ` Al Viro [this message]
2017-01-03 21:14 ` Dan Williams
2017-01-03 23:22 ` Al Viro
2017-01-03 23:46 ` Linus Torvalds
2017-01-04 0:57 ` Dan Williams
2017-01-04 1:38 ` Dan Williams
2017-01-04 1:59 ` Al Viro
2017-01-04 2:14 ` Dan Williams
2016-10-26 15:50 ` [PATCH v2 2/3] use a nocache copy for bvecs and kvecs in copy_from_iter_nocache() Brian Boylston
2016-10-27 4:46 ` Ross Zwisler
2016-10-26 15:50 ` [PATCH v2 3/3] x86: remove unneeded flush in arch_copy_from_iter_pmem() Brian Boylston
2016-10-26 19:57 ` Boaz Harrosh
2016-10-28 1:58 ` Boylston, Brian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170102050927.GY1555@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=boaz@plexistor.com \
--cc=boylston@burromesa.net \
--cc=dan.j.williams@intel.com \
--cc=elliott@hpe.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@ml01.01.org \
--cc=mingo@redhat.com \
--cc=oliver.moreno@hpe.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).