Dan Williams <dan.j.williams@xxxxxxxxx> writes: > On Mon, Apr 24, 2017 at 9:26 AM, Jeff Moyer <jmoyer@xxxxxxxxxx> wrote: >> Dan Williams <dan.j.williams@xxxxxxxxx> writes: >> >>> The nvdimm_flush() mechanism helps to reduce the impact of an ADR >>> (asynchronous-dimm-refresh) failure. The ADR mechanism handles flushing >>> platform WPQ (write-pending-queue) buffers when power is removed. The >>> nvdimm_flush() mechanism performs that same function on-demand. >>> >>> When a pmem namespace is associated with a block device, an >>> nvdimm_flush() is triggered with every block-layer REQ_FUA, or REQ_FLUSH >>> request. However, when a namespace is in device-dax mode, or namespaces >>> are disabled, userspace needs another path. >>> >>> The new 'flush' attribute is visible when it can be determined that the >>> interleave-set either does, or does not have DIMMs that expose WPQ-flush >>> addresses, "flush-hints" in ACPI NFIT terminology. It returns "1" and >>> flushes DIMMs, or returns "0" the flush operation is a platform nop. >>> >>> Signed-off-by: Dan Williams <dan.j.williams@xxxxxxxxx> >> >> NACK. This should function the same way it does for a pmem device. >> Wire up sync. > > We don't have dirty page tracking for device-dax, without that I don't > think we should wire up the current sync calls. Why not? Device dax is meant for the "flush from userspace" paradigm. There's enough special casing around device dax that I think you can get away with implementing *sync as call to nvdimm_flush. > I do think we need a more sophisticated sync syscall interface > eventually that can select which level of flushing is being performed > (page cache vs cpu cache vs platform-write-buffers). I don't. I think this whole notion of flush, and flush harder is brain-dead. How do you explain to applications when they should use each one? > Until then I think this sideband interface makes sense and sysfs is > more usable than an ioctl. Well, if you're totally against wiring up sync, then I say we forget about the deep flush completely. What's your use case? Cheers, Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
