On Wed, Dec 28, 2016 at 3:43 PM, Al Viro <viro(a)zeniv.linux.org.uk> wrote:
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
> >> 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?
Agreed, pmem has little to do with a cache avoiding memcpy. I believe
there are embedded platforms in the field that have system wide
batteries and arrange for cpu caches to be flushed on power loss. So a
cache avoiding memory copy may not always be the best choice for pmem.
More to the point, x86 implementation of that thing is tied to
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
it's pointless for kernel-to-kernel copies.
Yes, that's my turd and I agree we should opt for a generic cache
BTW, your "it's iovec, only non-temporal stores there"
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