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))
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?