On Mon, May 18, 2020 at 10:30 PM Aneesh Kumar K.V <aneesh.ku...@linux.ibm.com> wrote: > > > Hi Dan, > > Apologies for the delay in response. I was waiting for feedback from > hardware team before responding to this email. > > > Dan Williams <dan.j.willi...@intel.com> writes: > > > On Tue, May 12, 2020 at 8:47 PM Aneesh Kumar K.V > > <aneesh.ku...@linux.ibm.com> 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 persistent storage before any data > >> access or data transfer caused by subsequent instructions is initiated. > >> This is in addition to the ordering done by wmb() > >> > >> Update nvdimm core such that architecture can use barriers other than > >> wmb to ensure all previous writes are architecturally visible for > >> the platform buffer flush. > > > > This seems like an exceedingly bad idea, maybe I'm missing something. > > This implies that the deployed base of DAX applications using the old > > instruction sequence are going to regress on new hardware that > > requires the new instructions to be deployed. > > > pmdk support for ppc64 is still work in progress and there is pull > request to switch pmdk to use new instruction.
Ok. > > https://github.com/tuliom/pmdk/commit/fix-flush > > All userspace applications will be switched to use the new > instructions. The new instructions are designed such that when running on P8 > and P9 they behave as 'dcbf' and 'hwsync'. Sure, makes sense. > 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. Applications using new instructions behave as expected, the kernel has been shipping of_pmem and papr_scm for several cycles now, you're saying that the DAX applications written against those platforms are going to be broken on P8 and P9? > > I'm thinking the kernel > > should go as far as to disable DAX operation by default on new > > hardware until userspace asserts that it is prepared to switch to the > > new implementation. Is there any other way to ensure the forward > > compatibility of deployed ppc64 DAX applications? > > AFAIU there is no released persistent memory hardware on ppc64 platform > and we need to make sure before applications get enabled to use these > persistent memory devices, they should switch to use the new > instruction? Right, I want the kernel to offer some level of safety here because everything you are describing sounds like a flag day conversion. Am I misreading? Is there some other gate that prevents existing users of of_pmem and papr_scm from having their expectations violated when running on P8 / P9 hardware? Maybe there's tighter ecosystem control that I'm just not familiar with, I'm only going off the fact that the kernel has shipped a non-zero number of NVDIMM drivers that build with ARCH=ppc64 for several cycles.