Re: [PATCH v3] libnvdimm/region: Update nvdimm_has_flush() to handle explicit 'flush' callbacks

[Vaibhav Jain <vaibhav@linux.ibm.com>]

Thanks Pankaj for looking into this patch,

Pankaj Gupta <pankaj.gupta.linux@gmail.com> 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
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org