On Tue, May 19, 2020 at 6:53 AM Aneesh Kumar K.V <aneesh.ku...@linux.ibm.com> wrote: > > Dan Williams <dan.j.willi...@intel.com> writes: > > > On Mon, May 18, 2020 at 10:30 PM Aneesh Kumar K.V > > <aneesh.ku...@linux.ibm.com> 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. 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? > > The expecation is that both kernel and userspace would get upgraded to > use the new instruction before actual persistent memory devices are > made available. > > > > >> > 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. > > If we are looking at adding changes to kernel that will prevent a kernel > from running on newer hardware in a specific case, we could as well take > the changes to get the kernel use the newer instructions right?
Oh, no, I'm not talking about stopping the kernel from running. I'm simply recommending that support for MAP_SYNC mappings (userspace managed flushing) be disabled by default on PPC with either a compile-time or run-time default to assert that userspace has been audited for legacy applications or that the platform owner is otherwise willing to take the risk. > 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 have a pmem > device generally available, we get both kernel and userspace upgraded > to use these new instructions before such a device is made available. Ok, I think a compile time kernel option with a runtime override satisfies my concern. Does that work for you?
