Hi Dan, ADR is the platform capability which is default support in the Intel platform. (eADR is the extend capability to keep the cache as the persistent domain, not well support from the PRC customers)
So far, the customer use PMem would not consider the deep flush since 100% data security will not only leverage the single server, it will leverage the software (CRC, checksum) and distributed system. Deep flush is the smallest persistent domain and can assure that data persistent in any situation that might be useful for some Financial scenarios (didn't see in the PRC market so far). That's why options can be used for user to pick the data security level. GPF, as my understanding, still leverage the ADR from the original design and still the capability of the platform and have the chance to be failure. Thanks a lot and best regards, Dennis Wu -----Original Message----- From: Williams, Dan J <[email protected]> Sent: Wednesday, September 21, 2022 3:31 AM To: Christoph Hellwig <[email protected]>; Williams, Dan J <[email protected]> Cc: Christoph Hellwig <[email protected]>; Wu, Dennis <[email protected]>; [email protected]; Verma, Vishal L <[email protected]>; Jiang, Dave <[email protected]>; Weiny, Ira <[email protected]> Subject: Re: [PATCH] ACPI/NFIT: Add no_deepflush param to dynamic control flush operation Christoph Hellwig wrote: [..] > > Otherwise, by default the kernel should default to taking as much > > care as possible to push writes to the smallest failure domain possible. > > In which case we need remve the device dax direct map and MAP_SYNC. > Reducing the failure domain is not what fsync or REQ_OP_FLUSH are > about, they are about making changes durable. How durable is up to > your device implementation. But if you trust it only a little you > should not offer that half way option to start with. That's a good point, but (with my Linux kernel developer hat on) I would flip it around and make this the platform vendor's problem. If the platform vendor has validated ADR* and that platform power supplies maintain stable power in a powerloss scenario, then 'deepflush' is a complete nop, why publish a flush mechanism? In other words, unless the platform vendor has no confidence in the standard durability model (persistence / durability at global visibility outside the CPU cache) it should skip publishing these flush hints in the ACPI NFIT table. The recourse for an end user whose vendor has published this mechanism in error is to talk to their BIOS vendor to turn off the flush capability, or use the ACPI table override mechanism to edit out the flush capability. I will also note that CXL has done away with this software flush concept and defines a standard Global Persistence Flush mechanism in the protocol that fires at impending power-loss events. * ADR: Asynchronous DRAM refresh, a platform signal to flush write buffers in the device upon detection of power-loss.
