lkml.org 
[lkml]   [2016]   [Dec]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2 1/3] introduce memcpy_nocache()
    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?

    \
     
     \ /
      Last update: 2016-12-29 00:43    [W:3.171 / U:0.868 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site