Thanks Pankaj for looking into this patch, Pankaj Gupta <pankaj.gupta.linux@xxxxxxxxx> writes: > Hi Vaibhav, > >> In case a platform doesn't provide explicit flush-hints but provides an >> explicit flush callback, then nvdimm_has_flush() still returns '0' >> indicating that writes do not require flushing. This happens on PPC64 >> with patch at [1] applied, where 'deep_flush' of a region was denied >> even though an explicit flush function was provided. >> >> Similar problem is also seen with virtio-pmem where the 'deep_flush' >> sysfs attribute is not visible as in absence of any registered nvdimm, >> 'nd_region->ndr_mappings == 0'. > > In case of async flush callback, do we still need "deep_flush" ? 'deep_flush' in libnvdimm (specifically 'deep_flush_store()') anyways resorts to calling 'async_flush' callback if its defined. Which makes sense to me since in absence of eADR, 'echo 1 > deep_flush' would ensure that writes to pmem are now durable even if there is a sudden power loss before cpu caches are flushed. On non-nfit architectures the 'async_flush' callback should provide such a guarantee, which can be triggered by user-space writing to the 'deep_flush' sysfs attr. In absence of 'deep_flush' sysfs attr not sure how else can user-space forcibly trigger async_flush callback for dev-dax char devices. <snip> -- Cheers ~ Vaibhav
