Ross Zwisler <ross.zwisler(a)linux.intel.com> writes:
This series implements the very slow but correct handling for
blkdev_issue_flush() with DAX mappings, as discussed here:
I don't think that we can actually do the
...where sync_cache is something like:
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
So much for not violating the principal of least surprise. I suppose
you've asked the hardware folks, and they've sent you down this path?
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
Sure, but wbinvd would be quite costly as well. Either way I think a
better solution will be required in the near term.