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