On Thu, Sep 27, 2018 at 12:12 AM Johannes Thumshirn <[email protected]> wrote: > > On Wed, Sep 26, 2018 at 09:24:20PM -0700, Dan Williams wrote: > > The Intel NVDIMM command specification publishes a dirty-shutdown-count > > in addition to the dirty-shutdown / flush-failed indication that comes > > from the ACPI NFIT. This is expected to be a common property of NVDIMMs > > and is a static hardware health detail to be cached / exported via > > sysfs. > > > > Add plumbing for retrieving this data at driver load time, publish the > > count, and use the dynamically retrieved dirty-shutdown indicator to > > augment the existing 'flush_failed' flag. > > Is this the same thing as the LSS Latch stuff that went into ndctl?
It's a replacement. The latch mechanism is awkward especially when all that it needed is a rolling count of dirty-shutdown events. The expectation going forward is that the platform firmware will handle the latch, if it is present, and the OS need only consume the dirty-shutdown count. The ndctl implementation called libndctl apis from the udev queue which we discovered injects unnecessary udev queue drains / stalls into the boot path. Lastly, the userspace caching scheme for non-root users to consume the dirty-shutdown-count just isn't as efficient as teaching the kernel to cache this value and export it as a standard sysfs attribute. _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
