From: Al Viro <viro@ZenIV.linux.org.uk>
To: "Elliott, Robert (Persistent Memory)" <elliott@hpe.com>
Cc: "linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
"Moreno," Oliver" <oliver.moreno@hpe.com>,
"x86@kernel.org, " <x86@kernel.org>,
linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"boylston@burromesa.net" <boylston@burromesa.net>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>
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?
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
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: 51+ 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 ` Brian Boylston
2016-10-26 15:50 ` [PATCH v2 1/3] introduce memcpy_nocache() Brian Boylston
2016-10-26 15:50 ` Brian Boylston
2016-10-26 19:30 ` Thomas Gleixner
2016-10-28 1:52 ` Boylston, Brian
2016-10-28 1:52 ` Boylston, Brian
2016-10-26 19:51 ` Boaz Harrosh
2016-10-26 19:51 ` Boaz Harrosh
2016-10-28 1:54 ` Boylston, Brian
2016-10-28 1:54 ` Boylston, Brian
2016-11-01 14:25 ` Boaz Harrosh
2016-11-01 14:25 ` Boaz Harrosh
2016-12-28 23:43 ` Al Viro
2016-12-28 23:43 ` Al Viro
2016-12-29 18:23 ` Dan Williams
2016-12-29 18:23 ` Dan Williams
2016-12-30 3:52 ` Al Viro
2016-12-30 3:52 ` Al Viro
2016-12-30 4:56 ` Dan Williams
2016-12-30 4:56 ` Dan Williams
2016-12-31 2:25 ` [RFC] memcpy_nocache() and memcpy_writethrough() Al Viro
2016-12-31 2:25 ` Al Viro
2017-01-02 2:35 ` Elliott, Robert (Persistent Memory)
2017-01-02 2:35 ` Elliott, Robert (Persistent Memory)
2017-01-02 5:09 ` Al Viro [this message]
2017-01-02 5:09 ` Al Viro
2017-01-03 21:14 ` Dan Williams
2017-01-03 21:14 ` Dan Williams
2017-01-03 23:22 ` Al Viro
2017-01-03 23:22 ` Al Viro
2017-01-03 23:46 ` Linus Torvalds
2017-01-03 23:46 ` Linus Torvalds
2017-01-04 0:57 ` Dan Williams
2017-01-04 0:57 ` Dan Williams
2017-01-04 1:38 ` Dan Williams
2017-01-04 1:38 ` Dan Williams
2017-01-04 1:59 ` Al Viro
2017-01-04 1:59 ` Al Viro
2017-01-04 2:14 ` Dan Williams
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-26 15:50 ` Brian Boylston
2016-10-27 4:46 ` Ross Zwisler
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 15:50 ` Brian Boylston
2016-10-26 19:57 ` Boaz Harrosh
2016-10-26 19:57 ` Boaz Harrosh
2016-10-28 1:58 ` Boylston, Brian
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=elliott@hpe.com \
--cc=linux-nvdimm@lists.01.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.