On 2/18/20 12:45 PM, jane@oracle.com wrote:
On 2/18/20 11:50 AM, Jeff Moyer wrote:
Dan Williams writes:
Right now the kernel does not install a pte on faults that land on a
page with known poison, but only because the error clearing path is so
convoluted and could only claim that
On 2/18/20 11:50 AM, Jeff Moyer wrote:
Dan Williams writes:
Right now the kernel does not install a pte on faults that land on a
page with known poison, but only because the error clearing path is so
convoluted and could only claim that fallocate(PUNCH_HOLE) cleared
errors because that was
Dan Williams writes:
> Right now the kernel does not install a pte on faults that land on a
> page with known poison, but only because the error clearing path is so
> convoluted and could only claim that fallocate(PUNCH_HOLE) cleared
> errors because that was guaranteed to send 512-byte aligned
On Wed, Feb 5, 2020 at 12:27 PM wrote:
>
> Hello,
>
> I haven't seen response to this proposal, unsure if there is a different
> but related discussion ongoing...
>
> I'd like to express my wish: please make it easier for the pmem
> applications when possible.
>
> If kernel does not clear poison
Hello,
I haven't seen response to this proposal, unsure if there is a different
but related discussion ongoing...
I'd like to express my wish: please make it easier for the pmem
applications when possible.
If kernel does not clear poison when it could legitimately do so,
applications have to
On Wed, Jan 29, 2020 at 04:03:37PM -0500, Vivek Goyal wrote:
> I am looking into getting rid of dependency on block device in dax
> path. One such place is __dax_zero_page_range() which checks if
> range being zeroed is aligned to block device logical size, then
> it calls bdev_issue_zeroout()
I am looking into getting rid of dependency on block device in dax
path. One such place is __dax_zero_page_range() which checks if
range being zeroed is aligned to block device logical size, then
it calls bdev_issue_zeroout() instead of doing memset(). Calling
blkdev_issue_zeroout() also clears