Re: [PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier

2020-06-26 Thread Michal Suchánek
On Fri, May 22, 2020 at 09:01:17AM -0400, Mikulas Patocka wrote: > > > On Fri, 22 May 2020, Aneesh Kumar K.V wrote: > > > On 5/22/20 3:01 PM, Michal Suchánek wrote: > > > On Thu, May 21, 2020 at 02:52:30PM -0400, Mikulas Patocka wrote: > > > > > > > > > > > > On Thu, 21 May 2020, Dan

Re: [PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier

2020-05-22 Thread Mikulas Patocka
On Fri, 22 May 2020, Aneesh Kumar K.V wrote: > On 5/22/20 3:01 PM, Michal Suchánek wrote: > > On Thu, May 21, 2020 at 02:52:30PM -0400, Mikulas Patocka wrote: > > > > > > > > > On Thu, 21 May 2020, Dan Williams wrote: > > > > > > > On Thu, May 21, 2020 at 10:03 AM Aneesh Kumar K.V > > > >

Re: [PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier

2020-05-22 Thread Aneesh Kumar K.V
On 5/22/20 3:01 PM, Michal Suchánek wrote: On Thu, May 21, 2020 at 02:52:30PM -0400, Mikulas Patocka wrote: On Thu, 21 May 2020, Dan Williams wrote: On Thu, May 21, 2020 at 10:03 AM Aneesh Kumar K.V wrote: Moving on to the patch itself--Aneesh, have you audited other persistent memory

Re: [PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier

2020-05-22 Thread Michal Suchánek
On Thu, May 21, 2020 at 02:52:30PM -0400, Mikulas Patocka wrote: > > > On Thu, 21 May 2020, Dan Williams wrote: > > > On Thu, May 21, 2020 at 10:03 AM Aneesh Kumar K.V > > wrote: > > > > > > > Moving on to the patch itself--Aneesh, have you audited other persistent > > > > memory users in the

Re: [PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier

2020-05-21 Thread Mikulas Patocka
On Thu, 21 May 2020, Dan Williams wrote: > On Thu, May 21, 2020 at 10:03 AM Aneesh Kumar K.V > wrote: > > > > > Moving on to the patch itself--Aneesh, have you audited other persistent > > > memory users in the kernel? For example, drivers/md/dm-writecache.c does > > > this: > > > > > >

Re: [PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier

2020-05-21 Thread Dan Williams
On Thu, May 21, 2020 at 7:39 AM Jeff Moyer wrote: > > Dan Williams writes: > > >> But I agree with your concern that if we have older kernel/applications > >> that continue to use `dcbf` on future hardware we will end up > >> having issues w.r.t powerfail consistency. The plan is what you

Re: [PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier

2020-05-21 Thread Dan Williams
On Thu, May 21, 2020 at 10:03 AM Aneesh Kumar K.V wrote: > > On 5/21/20 8:08 PM, Jeff Moyer wrote: > > Dan Williams writes: > > > >>> But I agree with your concern that if we have older kernel/applications > >>> that continue to use `dcbf` on future hardware we will end up > >>> having issues

Re: [PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier

2020-05-21 Thread Aneesh Kumar K.V
On 5/21/20 8:08 PM, Jeff Moyer wrote: Dan Williams writes: But I agree with your concern that if we have older kernel/applications that continue to use `dcbf` on future hardware we will end up having issues w.r.t powerfail consistency. The plan is what you outlined above as tighter ecosystem

Re: [PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier

2020-05-21 Thread Jeff Moyer
Dan Williams writes: >> But I agree with your concern that if we have older kernel/applications >> that continue to use `dcbf` on future hardware we will end up >> having issues w.r.t powerfail consistency. The plan is what you outlined >> above as tighter ecosystem control. Considering we don't

Re: [PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier

2020-05-20 Thread Aneesh Kumar K.V
Dan Williams writes: > On Tue, May 19, 2020 at 6:53 AM Aneesh Kumar K.V > wrote: >> >> Dan Williams writes: >> >> > On Mon, May 18, 2020 at 10:30 PM Aneesh Kumar K.V >> > wrote: >> >> ... >> >> >> Applications using new instructions will behave as expected when running >> >> on P8 and P9.

Re: [PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier

2020-05-19 Thread Dan Williams
On Tue, May 19, 2020 at 6:53 AM Aneesh Kumar K.V wrote: > > Dan Williams writes: > > > On Mon, May 18, 2020 at 10:30 PM Aneesh Kumar K.V > > wrote: > > ... > > >> Applications using new instructions will behave as expected when running > >> on P8 and P9. Only future hardware will differentiate

Re: [PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier

2020-05-19 Thread Aneesh Kumar K.V
Dan Williams writes: > On Mon, May 18, 2020 at 10:30 PM Aneesh Kumar K.V > wrote: ... >> Applications using new instructions will behave as expected when running >> on P8 and P9. Only future hardware will differentiate between 'dcbf' and >> 'dcbfps' > > Right, this is the problem.

Re: [PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier

2020-05-19 Thread Dan Williams
On Mon, May 18, 2020 at 10:30 PM Aneesh Kumar K.V wrote: > > > Hi Dan, > > Apologies for the delay in response. I was waiting for feedback from > hardware team before responding to this email. > > > Dan Williams writes: > > > On Tue, May 12, 2020 at 8:47 PM Aneesh Kumar K.V > > wrote: > >> > >>

Re: [PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier

2020-05-18 Thread Aneesh Kumar K.V
Hi Dan, Apologies for the delay in response. I was waiting for feedback from hardware team before responding to this email. Dan Williams writes: > On Tue, May 12, 2020 at 8:47 PM Aneesh Kumar K.V > wrote: >> >> Architectures like ppc64 provide persistent memory specific barriers >> that

Re: [PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier

2020-05-13 Thread Dan Williams
On Tue, May 12, 2020 at 8:47 PM Aneesh Kumar K.V wrote: > > Architectures like ppc64 provide persistent memory specific barriers > that will ensure that all stores for which the modifications are > written to persistent storage by preceding dcbfps and dcbstps > instructions have updated

[PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier

2020-05-12 Thread Aneesh Kumar K.V
Architectures like ppc64 provide persistent memory specific barriers that will ensure that all stores for which the modifications are written to persistent storage by preceding dcbfps and dcbstps instructions have updated persistent storage before any data access or data transfer caused by