lkml.org 
[lkml]   [2020]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] pmem: export the symbols __copy_user_flushcache and __copy_from_user_flushcache
    On Wed, Sep 16, 2020 at 10:40:13AM -0700, Dan Williams wrote:
    > > Before nvfs gets included in the kernel, I need to distribute it as a
    > > module. So, it would make my maintenance easier. But if you don't want to
    > > export it now, no problem, I can just copy __copy_user_flushcache from the
    > > kernel to the module.
    >
    > That sounds a better plan than exporting symbols with no in-kernel consumer.

    Exporting symbols without a user is a complete no-go.

    > > > My first question about nvfs is how it compares to a daxfs with
    > > > executables and other binaries configured to use page cache with the
    > > > new per-file dax facility?
    > >
    > > nvfs is faster than dax-based filesystems on metadata-heavy operations
    > > because it doesn't have the overhead of the buffer cache and bios. See
    > > this: http://people.redhat.com/~mpatocka/nvfs/BENCHMARKS
    >
    > ...and that metadata problem is intractable upstream? Christoph poked
    > at bypassing the block layer for xfs metadata operations [1], I just
    > have not had time to carry that further.
    >
    > [1]: "xfs: use dax_direct_access for log writes", although it seems
    > he's dropped that branch from his xfs.git

    I've pushed the old branch out again:

    http://git.infradead.org/users/hch/xfs.git/shortlog/refs/heads/xfs-log-dax

    The main sticking points here are:

    - currently all our nvdimm/DAX code does totally pointless pmem_flush
    calls just to be on the safe side. That probably is one of the big
    speedups of nova and other academic snake oil projects over our
    stack. We need to handle this properly
    - what do we do about write error handling? That is the other big
    thing in the pmem/dax stack that all of the direct writers (including
    MAP_SYNC mmaps) pretty much ignore

    Once that is sorted out we can not just put the log changes like above
    in, but also move the buffer cache over to do a direct access and
    basically stop using the block layer for a pure DAX XFS.

    \
     
     \ /
      Last update: 2020-09-17 08:51    [W:3.136 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site