lkml.org 
[lkml]   [2015]   [Oct]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Subject[PATCH 0/2] "big hammer" for DAX msync/fsync correctness
    Date
    This series implements the very slow but correct handling for
    blkdev_issue_flush() with DAX mappings, as discussed here:

    https://lkml.org/lkml/2015/10/26/116

    I don't think that we can actually do the

    on_each_cpu(sync_cache, ...);

    ...where sync_cache is something like:

    cache_disable();
    wbinvd();
    pcommit();
    cache_enable();

    solution as proposed by Dan because WBINVD + PCOMMIT doesn't guarantee that
    your writes actually make it durably onto the DIMMs. I believe you really do
    need to loop through the cache lines, flush them with CLWB, then fence and
    PCOMMIT.

    I do worry that the cost of blindly flushing the entire PMEM namespace on each
    fsync or msync will be prohibitively expensive, and that we'll by very
    incentivized to move to the radix tree based dirty page tracking as soon as
    possible. :)

    Ross Zwisler (2):
    pmem: add wb_cache_pmem() to the PMEM API
    pmem: Add simple and slow fsync/msync support

    arch/x86/include/asm/pmem.h | 11 ++++++-----
    drivers/nvdimm/pmem.c | 10 +++++++++-
    include/linux/pmem.h | 22 +++++++++++++++++++++-
    3 files changed, 36 insertions(+), 7 deletions(-)

    --
    2.1.0



    \
     
     \ /
      Last update: 2015-10-28 23:21    [W:9.015 / U:0.000 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site