From: Al Viro <viro@ZenIV.linux.org.uk>
To: Dan Williams <dan.j.williams@intel.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>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
"boylston@burromesa.net" <boylston@burromesa.net>
Subject: Re: [PATCH v2 1/3] introduce memcpy_nocache()
Date: Fri, 30 Dec 2016 03:52:52 +0000 [thread overview]
Message-ID: <20161230035252.GV1555@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CAPcyv4gg1XNJ3E=+0HDZnx08_dvvX+Prj-rLOsXcuHHO1pBLzg@mail.gmail.com>
On Thu, Dec 29, 2016 at 10:23:15AM -0800, Dan Williams wrote:
> > BTW, your "it's iovec, only non-temporal stores there" logics in
> > arch_copy_from_iter_pmem() is simply wrong - for one thing, unaligned
> > copies will have parts done via normal stores, for another 32bit will
> > _not_ go for non-caching codepath for short copies. What semantics do
> > we really need there?
>
> For typical pmem platforms we need to make sure all the writes are on
> the way to memory such than a later sfence can guarantee that all
> previous writes are visible to the platform "ADR" logic. ADR handles
> flushing memory controller write buffers to media. At a minimum
> arch_copy_from_iter_pmem() needs to trigger a clwb (unordered cache
> line writeback) of each touched cache line if it is not using a cache
> bypassing store.
Um... Then we do have a problem - nocache variant of uaccess primitives
does *not* guarantee that clwb is redundant.
What about the requirements of e.g. tcp_sendmsg() with its use of
skb_add_data_nocache()? What warranties do we need there?
_______________________________________________
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: Dan Williams <dan.j.williams@intel.com>
Cc: 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>
Subject: Re: [PATCH v2 1/3] introduce memcpy_nocache()
Date: Fri, 30 Dec 2016 03:52:52 +0000 [thread overview]
Message-ID: <20161230035252.GV1555@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CAPcyv4gg1XNJ3E=+0HDZnx08_dvvX+Prj-rLOsXcuHHO1pBLzg@mail.gmail.com>
On Thu, Dec 29, 2016 at 10:23:15AM -0800, Dan Williams wrote:
> > BTW, your "it's iovec, only non-temporal stores there" logics in
> > arch_copy_from_iter_pmem() is simply wrong - for one thing, unaligned
> > copies will have parts done via normal stores, for another 32bit will
> > _not_ go for non-caching codepath for short copies. What semantics do
> > we really need there?
>
> For typical pmem platforms we need to make sure all the writes are on
> the way to memory such than a later sfence can guarantee that all
> previous writes are visible to the platform "ADR" logic. ADR handles
> flushing memory controller write buffers to media. At a minimum
> arch_copy_from_iter_pmem() needs to trigger a clwb (unordered cache
> line writeback) of each touched cache line if it is not using a cache
> bypassing store.
Um... Then we do have a problem - nocache variant of uaccess primitives
does *not* guarantee that clwb is redundant.
What about the requirements of e.g. tcp_sendmsg() with its use of
skb_add_data_nocache()? What warranties do we need there?
next prev parent reply other threads:[~2016-12-30 3:53 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 [this message]
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
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=20161230035252.GV1555@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=dan.j.williams@intel.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.