From: Al Viro <viro@ZenIV.linux.org.uk>
To: Boaz Harrosh <boaz@plexistor.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: Wed, 28 Dec 2016 23:43:22 +0000 [thread overview]
Message-ID: <20161228234321.GA27417@ZenIV.linux.org.uk> (raw)
In-Reply-To: <5818A5C8.6040300@plexistor.com>
On Tue, Nov 01, 2016 at 04:25:12PM +0200, Boaz Harrosh wrote:
> >> What about memcpy_to_pmem() in linux/pmem.h it already has all the arch switches.
> >>
> >> Feels bad to add yet just another arch switch over __copy_user_nocache
> >>
> >> Just feels like too many things that do the same thing. Sigh
> >
> > I agree that this looks like a nicer path.
> >
> > I had considered adjusting copy_from_iter_nocache() to use memcpy_to_pmem(),
> > but lib/iov_iter.c doesn't currently #include linux/pmem.h. Would it be
> > acceptable to add it? Also, I wasn't sure if memcpy_to_pmem() would always
> > mean exactly "memcpy nocache".
> >
>
> I think this is the way to go. In my opinion there is no reason why not to include
> pmem.h into lib/iov_iter.c.
>
> And I think memcpy_to_pmem() would always be the fastest arch way to bypass cache
> so it should be safe to use this for all cases. It is so in the arches that support
> this now, and I cannot imagine a theoretical arch that would differ. But let the
> specific arch people holler if this steps on their tows, later when they care about
> this at all.
First of all, if it's the fastest arch way to bypass cache, why the hell
is it sitting in pmem-related areas?
More to the point, x86 implementation of that thing is tied to uaccess API
for no damn reason whatsoever. Let's add a real memcpy_nocache() and
be done with that. I mean, this
if (WARN(rem, "%s: fault copying %p <- %p unwritten: %d\n",
__func__, dst, src, rem))
BUG();
is *screaming* "API misused here". And let's stay away from the STAC et.al. -
it's pointless for kernel-to-kernel copies.
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?
_______________________________________________
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: Boaz Harrosh <boaz@plexistor.com>
Cc: "Boylston, Brian" <brian.boylston@hpe.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: Wed, 28 Dec 2016 23:43:22 +0000 [thread overview]
Message-ID: <20161228234321.GA27417@ZenIV.linux.org.uk> (raw)
In-Reply-To: <5818A5C8.6040300@plexistor.com>
On Tue, Nov 01, 2016 at 04:25:12PM +0200, Boaz Harrosh wrote:
> >> What about memcpy_to_pmem() in linux/pmem.h it already has all the arch switches.
> >>
> >> Feels bad to add yet just another arch switch over __copy_user_nocache
> >>
> >> Just feels like too many things that do the same thing. Sigh
> >
> > I agree that this looks like a nicer path.
> >
> > I had considered adjusting copy_from_iter_nocache() to use memcpy_to_pmem(),
> > but lib/iov_iter.c doesn't currently #include linux/pmem.h. Would it be
> > acceptable to add it? Also, I wasn't sure if memcpy_to_pmem() would always
> > mean exactly "memcpy nocache".
> >
>
> I think this is the way to go. In my opinion there is no reason why not to include
> pmem.h into lib/iov_iter.c.
>
> And I think memcpy_to_pmem() would always be the fastest arch way to bypass cache
> so it should be safe to use this for all cases. It is so in the arches that support
> this now, and I cannot imagine a theoretical arch that would differ. But let the
> specific arch people holler if this steps on their tows, later when they care about
> this at all.
First of all, if it's the fastest arch way to bypass cache, why the hell
is it sitting in pmem-related areas?
More to the point, x86 implementation of that thing is tied to uaccess API
for no damn reason whatsoever. Let's add a real memcpy_nocache() and
be done with that. I mean, this
if (WARN(rem, "%s: fault copying %p <- %p unwritten: %d\n",
__func__, dst, src, rem))
BUG();
is *screaming* "API misused here". And let's stay away from the STAC et.al. -
it's pointless for kernel-to-kernel copies.
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?
next prev parent reply other threads:[~2016-12-28 23:43 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 [this message]
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
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=20161228234321.GA27417@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=boaz@plexistor.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.